xml-dev - Re: It's the syntax. . .

["W. E. Perry" <wperry@fiduciary.com>]

Thank you very much for a thoughtful and detailed reply:

"Eve L. Maler" wrote:

> I'm sorry, but speaking as someone who was there, I disagree entirely with
> your perspective on the history of XML.  It is solely about syntax
> precisely *because* we knew it was impossible to anticipate the semantic
> needs of the world in a single standard; we fully expected all these
> various semantic efforts to get going.

I do not think we are very far apart here, given the difference of
our
viewpoints. I am obviously inferring motivation from an
historian's
perspective, whereas you are recalling your intentions and
expectations as a
first-party participant. Nonetheless, you assert my two principal
points:  1)
it (that is, XML 1.0 as promulgated) *is* solely about syntax;
and  2) it was
(is) impossible to anticipate the semantic needs of the world in a
single
standard. Naturally, I would go further than you may be persuaded,
in
contending that the various follow-on semantic efforts have, each
in its own
purview, behaved as if the semantic needs of the world could be
anticipated,
and prescribed for, in a single standard.

> Also, we didn't invent well-formedness in order to eliminate the need for
> shared semantics; the original reason was to reduce bandwidth where the DTD
> (but really, the semantics, since DTDs have very little meaning all by
> themselves) was agreed on beforehand.

Again, we are not that far apart, given your contemporary versus
my historical
perspective on intent. I would argue that, whatever the intent,
the primary
effect of WF was to open at least the possibility of eliminating
(explicitly)
shared semantics, as a legitimate and equal alternative to the
pre-agreed
semantics of the DTD. That is (by far!) the single most
significant innovation
of XML. To me, the inescapable principal consequence of that
innovation is to
force us to pay attention to the markup on its own terms.

>  Being in possession of a single well-formed XML document, with no other
> information at hand to say how to interpret it, is extremely uninteresting.

Extremely challenging, yes, yet not only not uninteresting
(sorry!) but, to me
the central problem and greatest fascination of XML processing.
And, in fact,
there is a great deal of information to hand for interpreting the
document.
Appropriate questions for determining how to interpret--that is,
to process--it
include:
    what processing am I, as a node, capable of?  what information
to work upon
does that processing require?  is there in this document any such
information,
or indications of where and how to find or derive it?

> Even "autonomous, largely anonymous nodes" need a shared context in which
> to exchange information.

Yes, but the *shared* portion of that context may consist
principally of the
information itself. Each node also has its internal, private
context, within
which the interpretation, and therefore the appropriate processing
of the data,
may appear very different than within the context of the other
node.

>  If the point is to share information, then I don't see how standardized
> semantics can be considered a bottleneck.

They are, in fact, the principal bottleneck in such operations,
and often fatal
to a useful outcome. The point of putting this information onto a
network was
to expose it to a vastly larger audience than was otherwise
possible. Most of
those many additional nodes do not share a broad basis for common
syntax,
precisely because they were not previously part of the club (or
vertical
market, or common business practices) which agreed on those
semantics at a time
when the new majority of nodes were still inaccessible. There is
no choice in
many cases--and the general case should be--that the only workable
common
denominator of semantics is no shared semantics at all, only
markup syntax.

>  I just called a fabric-cleaning person on the phone today, someone I've
> never
> met before.  I wouldn't have gotten anywhere if I'd simply said
> "subject-verb-object" to him, but because I could safely assume he spoke
> English, and knew something about fabric cleaning,

You make the assumption, but *he* has to implement it--in
processing. He may
well be hiding from you that he does not understand English, or
even that he
cannot understand from your message that it has anything to do
with fabric
cleaning. What if this was, in fact, a worst case miscommunication
and he
defaulted to a crude brute-force solution:  he replied to your
message with a
statement of every service he was able to offer (there probably
aren't that
many), and you ignored what appeared to be gibberish until you
received, and
replied to (perhaps with modifications) the one thing--an offer of
fabric
cleaning--which made sense to you in the context of the
conversation you
thought you were conducting. At that point, you and he have the
basis for
ongoing conversation--in fact, for stepwise refinement and
agreement to a
transaction.

> Different parties may want to perform different processing (e.g.,
> translation of text vs. formatting it), but share a common understanding of
> what the content means in order to perform their different tasks
> successfully.  Or they may want to use different subsets of the shared
> information.  Or use different augmented *supersets* of the shared
> information.  Or it may be more efficient for the recipient to do the
> processing than the sender.  XML's standardized syntax facilitates all of
> these situations where nothing else could before.

I couldn't agree with this more. It is XML's standardized *syntax*
on which all
of these possibilities depend. Simple well-formedness enables any
of this
processing, within the context of how the node doing the
processing understands
the data and is capable of handling it. Yet as soon as one node
tries to force
its semantics along with the data onto another node whose internal
structures
and methods it does not know, it may preclude if those semantics
are heeded the
very structure into which the other node might have instantiated
the data and
thereby understood how to process it in some useful fashion.

> I don't mean to trivialize your points by eliding them, but I have no idea
> what it means to have a processor of XML (higher-level than a true "XML
> processor") that *doesn't* depend on semantics.  You can't glean any hidden
> instructions for what to do with XML stuff by merely parsing it; you need
> something in addition that tells you either (a) what things "mean" (perhaps
> in prose or perhaps by reference to shared semantical nuggets) or (b) what
> to do with them (something executable).

Yes, you do, but the greatest part of that is context and
capability internal
to the node doing the processing.

Respectfully,

Walter Perry

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************