[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: The general XML processing problem

• To: "'W. E. Perry'" <wperry@f...>, XML DEV <xml-dev@l...>
• Subject: RE: The general XML processing problem
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Mon, 15 Jul 2002 12:12:01 -0500

Not necessarily.  Either

a) You are instructed in how SYSTEM XYZ intends to process, 
or simply, precisely what it intends to return (the type 
commitment - precision is THE question here).

b) You have a way to instruct SYSTEM XYZ with instructions it understands.

Semantics require symbol-grounding, the apriori process of assigning meaning 
to signs.  XML doesn't care.  XML systems can and that level above 
the markup where processing occurs does require a system contract and a 
system for creating contracts to exchange data and have it processed 
by a means to which parties commit in advance through committing to 
what is returned or committing to the process.   Schemas are a 
a way to say "here is what I think you asked for" and the reason 
for PUBLIC IDs is to assert that one is obeying a public contract. 

We don't have to get wrapped around the existential 
issues of whether or not zero is a quantity or simply a notational 
convenience.  Somewhere, a byte changes state (Goldfarb).

The difficulty is "end to end" or "blind interoperability".  I 
don't believe that to be possible outside a very narrow system 
definition.   It is the Schrodinger's Cat problem.

len

-----Original Message-----
From: W. E. Perry [mailto:wperry@f...]

Joe English wrote:

> The best answer to the question "How does an XML document indicate how it
> should be processed?" is "It doesn't."
>
> "How does an XML document indicate how it should be processed *in system
> XYZ*?"  can be answered by system XYZ.

This is a wonderfully succinct statement of the consequences of data being
autonomous from process. I would love to think that we could say 'Amen' and
leave the matter here at rest. I have, however, reluctantly concluded that
the desire for documents to express authorial intent or preference is simply
too strong and too widely held to be overcome even by repeated demonstration
of the superior usefulness of a simpler, loosely-coupled architecture.
End-to-end enforcement of the narrow intent of an original author pervades
monolithic process designs. XML gives us the opportunity for more versatile,
more reusable, and less brittle processes, but only if we understand,
respect, and enforce the difference between data and instruction.

> (XML 1.0 even defines a handy place to put such instructions -- in an
> <?XYZ ...?> PI -- but for some reason that's considered heretical.)

It is heretical, if it presumes enough a priori knowledge of process XYZ to
be comfortable instructing that process in the execution of its own
functions.

• Prev by Date: Re: The general XML processing problem
• Next by Date: Re: The general XML processing problem
• Previous by thread: Trigram tables
• Next by thread: RE: The general XML processing problem
• Index(es):
  • Date
  • Thread