Proposed restatement of syntax-based interoperability principle ( was RE: Action item on syntax-based interoperability)

Dan Connolly wrote:

> If you find a moment to suggest an elaboration/revision, I'd
> appreciate it.



I strongly agree with Dan that the current proposal overstates the case for
syntax-based interoperability. Here is how I would handle Tim's action item
in some parallel universe where it was assigned to me:

========================================================================

The Web, like most information systems, has some important interfaces that
are defined in terms of APIs and reference data models, and some defined in
terms of the syntax, content, and sequence of messages interchanged. While
there are many well-founded arguments on either side of the debate over
whether syntax or data model should take precedence, ultimately they are
deeply intertwined and mutually supportive. In the case of XML, it's
syntactical structure of nested elements, attributes, and text strongly
implies something like the XML Infoset as a reference data model.  Most XML
"processing" specifications -- including SAX, DOM, CSS, XPath/XSLT, and
Xquery -- implicitly or explicitly are defined in terms of the reference
data model rather than the XML syntax, allowing them to avoid burdening the
specs with rules about the handling of syntactical structures that are
widely considered to be equivalent, such as "<empty></empty>" and
"<empty/>".  On the other hand, real data interoperability needs at least a
lowest-common-denominator definition of the reference serialization format
for the data model, so data interchange specifications are generally defined
in terms of XML syntax.

The standardized, textual "bits on the wire" definition of important
standards such as HTTP, HTML, and XML has contributed greatly to the success
of the Web.
It commonly occurs  that programmers working with the Web write code
directly to generate and parse these messages.  It is not uncommon for
end-users to have direct exposure to these messages.  This leads to the
well-known "view source" effect, whereby users gain expertise in the
workings of the systems by direct exposure to the underlying protocols. 

The "view source principle" should be treated respectfully, but it must be
weighed against other requirements and constraints on the Web architecture.
As the Web technologies have become more and more mission critical to
businesses, and to the extent that actual evidence shows that there are real
bottlenecks in enterprise applications due to the overhead of the specific
message syntaxes, there will be an understandable urge to define more
efficient serialization formats for one or more flavors of the XML Infoset.
So long as alternatives that do not support the view source principle are
treated as optimizations for the special case in which parties to a message
negotiate their ability to handle the alternative serialization in advance,
and that conformant systems are required to fall back to the text-based
standard if that negotiation fails, such formats should be treated as
possible alternative solutions to the engineering problem of balancing
readability, message size, and processing efficiency and not as antithetical
to the Web architecture.

Abstract data models such as that of XQuery, and APIs such as DOM, have
played and will increasingly play an important role in Web applications.
For example, Xquery's ability to process data sources that are not in XML
format (such as relational DBMS tables), and DOM's ability to enable dynamic
HTML applications in a world where few web pages are valid instances of any
(X)HTML Recommendation, give them practical advantages to end users that
sometimes outweigh the real-world benefits of a purely syntactical
definition of Web standards. Nevertheless, the general success of Web
software is evidence that interoperability in networked information systems
is best achieved when interfaces specified at the level of concrete syntax
are available as the default mode of interaction, to be recommended for use
in the absence of compelling requirements or use cases for alternatives.

=========================================================================

I have no reason to think that this would be acceptable to the TAG, but
perhaps some bits can be harvested to tone down Tim's proposed text.

Received on Thursday, 23 October 2003 19:14:34 UTC