[
Lists Home |
Date Index |
Thread Index
]
"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
|
