XML protocols principles (was Re: Let's get some principles nailed down)

> CP1. When designing a data format to be used in representing Web Resources, 
> the use of XML should be considered carefully.

Does this imply the XML 1.0 syntax, or the XML Infoset data model?  If the 
former, then SOAP 1.2 (and XForms (?), WSDL 1.2, XSLT, and probably many 
more
W3C specs are not "compliant."  If the latter, some argue that the Infoset
spec itself is underspecified for the task.  [I'll let Elliotte Harold 
carry this ball :-)  ]

This sounds like a rathole to me, if some precise definition of  "XML" is 
implied, or else just is a vague exhortation that no reasonable person is 
likely to disagree with at this point.

> CP3. When using XML, designers SHOULD NOT introduce syntax constraints beyond 
> those involved in the definition of XML.

Uhh, is this a shot across SOAP's bow?  Or am I getting paranoid in my 
declining years?

Not speaking for the Web Services Architecture WG, but expressing concerns 
raised at
our recent F2F, one can make a plausible argument that the "definition of 
XML" needs
some work (or a profile defined) to address some of the challenges (e.g. 
with
composability, performance, and interoperable implementations of the more 
complex
bits of the XML corpus) that people are facing in practice.

> CP11. Designers of protocols should give serious consideration to avoiding 
> such design activities in favor of existing well-established protocols 
> such as HTTP that fit well into REST.

I think I agree with the sentiment here, but am concerned with the "avoid 
such design activities" wording.  I would encourage the TAG to *not* put 
out the message "the Web is done, stick a fork in it."  The
Web, like everything else, is evolving; what we have now came to be because
it built on the pieces that came before in ways their inventors didn't 
envision.
(Sometimes for the better, sometimes for the worse!) Stating the principle 
that
new protocols should leverage and/or interoperate with the existing Web 
seems
like a better starting point than "avoid such design activities in favor of 
existing
protocols."

For example, many of us might be skeptical that a simple application of 
XML+HTTP
to the RPC paradigm will lead the Web to its full potential.  On the other 
hand,
I for one am very glad that the TAG wasn't around to discourage those "design 
 activities", over-hyped as the results may have been.  Better to give 
advice on which innovations are likely to be most successful in the context
of the principles of the Web than to discourage innovation that breaks the 
rules
as we currently understand them.  Where would we be today if y'all hadn't
broken "the rules" 5-10-15 years ago?

Received on Monday, 18 November 2002 15:00:14 UTC