Re: Action item on syntax-based interoperability

Tim Bray writes:

"The general success of Web software is evidence that interoperability 
in networked information systems is best achieved by specifying 
interfaces at the level of concrete syntax rather than abstract data 
models or APIs."

I would strongly urge the TAG to just not try to say anything authoritative
along these lines.  Certainly a reasonable case can be made for Tim's
position, and it's certainly true that the standardized "bits on the wire"
that are viewable as ordinary text has contributed to the rapid spread of
HTTP and HTML.  I'm very uncomfortable with elevating all this to the level
of a general principle.  As Dare and others have mentioned, the Infoset (and
its numerous variants) have contributed to at least the *specifications* for
Web-related tools such as DOM, SOAP, Xinclude, etc.  How about XSLT?  It is
most definitely an important part of the Web as I understand the term, but
most definitely not defined at the level of concrete syntax. The fact that
these specs are defined on the post-parse data model rather than concrete
syntax probably complicates the job of people struggling to deal with
features that are in the XML syntax but not the Infoset, but that strikes me
as evidence of a layering problem in XML rather than a realistic critique of
the Infoset-based specs. 

As for namespaces, I speak from extremely bitter personal experience [Lauren
may have mentioned something along these lines to you once or twice, Tim :-)
]  that the fact that the Namespaces spec is defined solely in terms of the
syntax and what should happen at parse time greatly complicated the work of
the DOM WG. I'm reasonably sure that the XSLT specifiers and developers have
had similar experiences. The divergences among the various Infoset-like data
models (DOM, Xpath) are largely related to how they model namespaces.  This
is not to re-open old wounds, but simply to point out that basing specs on
the syntax rather than Infoset is hardly a cure-all for conceptual confusion
or interoperable implementation.

More generally I really think this sends the wrong message going forward to
the Xpath/Xquery and SOAP communities, who have very explicit use cases for
defining their processing models on the Infoset rather than the syntax.
Would an Xquery query of a relational DBMS that has no XML representation
until Xquery serializes the results as XML be un-Weblike?    

I would prefer for the TAG to acknowledge that the XML syntax is and should
be the common denominator at which interoperability is more easily defined,
but that real XML specs and tools find great benefit from operating at the
Infoset (broadly defined) level.  Going forward, I'd like you folks to say
something like that so long as the XML syntax is the fallback in some
content negotiation, interoperability AND improved efficiency are possible
(or at least viable paths to explore without violating the principles of the
Web Arch).  I'm sure that Elliotte and Simon and others will vigorously
dispute this opinion, but that's the whole point: It's not something that we
as a community really have any consensus at all on, and if the TAG takes a
position toward one extreme of the continuum, it will detract from the goals
of the Web Arch document and the TAG itself.

Received on Thursday, 23 October 2003 11:29:42 UTC