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 o
 "W. E. Perry" wrote: > >... > > For several years now I have advocated this approach as the basis of an XML > processing model. Logically implemented, however, it contradicts what is in > practice a central dogma of XML orthodoxy. The question is whether an > XML-consuming application ought to be built around the data structures as > interchanged or should rather use a private local data structure best suited > to the application's own implementation of some particular expertise. The use of the word "data structure" is confusing. I see "data structure" as being an aspect of implementation and unrelated to the data on the wire. A purchase order schema is not defining a "data structure", it is defining an XML "vocabulary" or "file format". I will defend to the death the right of applications to define their own implementation data structures without any concern whatsoever for the rest of the world. But I cannot understand why you deny the widely held belief (held both inside and outside the XML world) that the signature of a function is both its input and its output and that both should be defined formally. If the XML world is mislead, it is not by the SGML tradition but by mathematical tradition! >... > Validation, whether by DTD, schema, or otherwise, is grounded in the > expectation that an XML-consuming application adheres to a contract to process > only input which conforms to a pre-agreed schematic. Well, no, there are (at least?) three different roles for input validation. The first is merely to offload syntactic error checking from your application to a purpose-built component, the schema validator. The second is to communicate these expectations to a third party (to create either a compatible producer application or an alternate consumer application). The third is to build agreement between multiple parties before implementation begins. I believe you are concentrating on the last. >... > There is a fundamental divide between believing in one case that the first > priority of an XML-consuming application is to adhere to, and to enforce, the > schematic contract which is perceived as the basis of document > interchangeability, and believing in the other case that the point of an > application is to apply specific expertise in process, which includes > particular, and probably private, judgments about what input data to accept, > and generally about where and to get the data that the application's expertise > requires. It would really help if you could provide some specific, concrete examples. The usual model is that in order to buy something you submit a purchase order in a well-known vocabulary and receive in return a receipt (modulo all kinds of negotiations, acceptance protocols, etc.). Input->function->output. Input and output are publically, formally defined. The function is defined only by its implementation. I can show this in mind-numbing syntactic detail if it helps. Now what does your model look like? > ... The autonomous processing nodes of the > internetwork topology are of value because of what they produce, which is to > say the expertise which they implement. Not necessarily. Sometimes they are of value simply because they know how to accept information. It is the *side effects* of this information acceptance (i.e. the shipping of running shoes to a consumer) that is of value. The same goes for email. My computer produces little interesting output after accepting an email. Perhaps you differ in your view of the architecture because you have a different problem domain than most other people. > ... > I do try to extend this point, however, by noticing that the most > accurate and effective discovery about a process is in the examination of its output. How do you get the output until you've given input? When you say "discovery" do you mean the human being looking out the output at design time or the runtime software process doing so without human intervention? I can't say I enjoy picking through electronic scat but neither do I know how to write a program that can do it. > ... It > is less interesting and less valuable than a true pipeline because it fails to > harness the specific expertise of each successive process, which much necessarily > include expertise in selecting which data to work on, and how, regardless of what is > presented. How can a process select the data it will work upon without a priori knowledge of the semantics of the element types. If you use "P" to mean paragraph and I use it to mean purchase order (perhaps even with the same namespace qualification) then the process cannot reliably act on the data it receives from us. I feel, therefore, that semantics must be agreed upon in advance (or at least mappable to agreed semantics). Standardizing syntax in a schema at the same time bolsters this semantic agreement and makes application writing easier. -- Paul Prescod 
|
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
|
|||||||||
