Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: A multi-step approach on defining object-oriented nature
 "Bullard, Claude L (Len)" wrote: > Discovery by output has the aggravation that the output may not be regular from instance > to instance. Which, if it is the case, is already a feature which the consuming application has to deal with anyway. And, yes, this does happen in the real world (it is true in some months of as much as 20% of the data which my applications must consume) and it is a problem utterly incapable of solution by schema, or in the general case by any fixed a priori agreements. > Or one could say that one should be looking at the output of another process that defines > the output of the others. Why add this layer of indirection when we already understand that we are not relying on the authority of a priori agreements, and a third party which merely makes empirical observation of the behavior of processes is not doing anything which an XML-consuming application could not, and should not, do for itself. > This is something like the process of analyzing print documents to create schemata for > them. One has to be sure the set is exhaustive or one comes back to rework. Perhaps so, if we were analyzing them in order to derive generalized schemata, but I propose that this is emphatically not what we are doing. Instead, the XML-consuming process is examining an instance document to determine whether in that particular instance, or in some other document which could be located and fetched based on the information in that instance, is there what the XML-consuming application requires to instantiate some particular bit of data which it requires for one instance execution of its processing. > As said in the past, even when schemata aren't used in the communication pipeline, in > the design pipeline, they can be invaluable. If as an output of that process, one gets a > definition which is exhaustive, that is, any transaction will be valid under it, then it > is better to read the schema. The design of an application is in large part the design of its appropriate internal data structure. If we are talking about the schema for that structure, then that is emphatically not the schema which might be considered to govern the form of document interchange between processes and thereby to enforce a 'contract' at the input or invocation interface side of an application. Indeed, my primary point is that we cannot rely on any ostensible input-side schema, even when all observed input instances conform to it, if our design goal to to build an application predicated on the best implementation of its own expertise, including a necessary expertise in input data collection and instantiation. > I say where namespaces are used, there should be a document somewhere but I prefer such > documents for any XML output. > If the http: URI is used, it should, in good conscience, point to a document should > inspection ever be required. Why? What can it possibly give you except an accurate description of an instance which you could get directly? And you run the considerable risk that the schematic is out-of-date or simply doesn't describe an exceptional instance which is the thing of interest to you. > Sure, there are XML instances without very long lifecycles or when opened, are glaringly > obvious as to what is intended. Every situation has exceptions. To me, the spec is fine > as is by not requiring such, but we are better off by the practice. Humans still have > some decisions to make. Indeed they do, but in my opinion they should be basing those decisions on the data instances which they have actually got rather than upon some authority which purports to govern such instances. (This gulf between revelatio and auctoritas is certainly nothing new). Respectfully, Walter Perry 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
