Re: Comments on draft-hollenbeck-ietf-xml-guidelines-02.txt

["Yaron Y. Goland" <modulus@xxxxxxxxxxx>]

While I agree that using a HTTP URL is sub-optimal for an XML namespaces
due to the expectation that it can be de-referenced I have never had any
sort of operational problem using URNs or other URIs in deployed XML
protocols. Since it sounds like this issue has been beaten to death I
wonder if any of those opposing the use of URIs has any articles that
explain the issue in the context of protocols.

RDDL is neat in that it provides a single point of description but it is
really most applicable for long lived XML documents, not protocol
messages.

In a protocol one doesn't generally provide too much data
describing the message. Rather one sends along (ideally) a single
identifier that says "I am defined by X" and either the destination
understands X or the communication fails. (NOTE: I am not talking about
'ignore this if you don't understand it' functionality)

Generally speaking the destination won't even try to de-reference X to see
if it can 'dynamically support' the protocol because there are just too
many semantic issues that can not be programmatically expressed. There may
be exceptions some day where de-referencing X might produce XSL transforms
that can be applied to the incoming message to translate it to a known
format but for the foreseable future that is generally not a workable
strategy due to subtle variations in meaning between the source and
destination protocol message formats.

So I strongly doubt you would ever see a RDDL being sent inside of a
protocol communication. It would be useful, however, inside of various
schema documents (e.g. SOAP, WSDL, UDDI, etc.).

I think we should keep in mind that this document is not meant as a
general description of good XML behavior, it is specifically meant as a
description of good XML protocol behavior and hence restrictions that
would not necessarily make sense generally do make sense here.

			Yaron

P.S. It is in the sense of the previous paragraph that I think it fine to
recommend against the use of attributes in this document. The attributes
vs. element debate has occured in the general XML context. This is not the
general XML context. This is the 'use of XML in protocol messages'
context. A much more restricted world. Just as such a world is served just
fine by a single URI as the XML namespace so it is best served via
attributes not elements. Due to the long deployment times of protocols it
is necessary when extending them to ensure that it can be done in a
backwards compatible way.

Think of HTTP where one can throw in a new header and the worst thing that
happens is that the header is ignored. The ability to throw in a new
command with a 'ignore this if you don't understand it' semantic is that
it means you don't have to first negotiate with the person you are talking
to in order to find out if they support the new command you want to send.

This is critical in protocols because round trips take a long time. While
bandwidth may be forever increasing the speed of light isn't going
anywhere. So optimizing for latency is going to be the primary protocol
design challenge, pretty much forever.

As I discuss in http://www.goland.org/rpc.htm it takes 0.04 seconds for a
beam of light to travel from one point on the equator to it's opposite
point and that assumes that a hole has been drilled through the middle of
the earth and filled with a perfect vacuum.

On 30 Apr 2002, Simon St.Laurent wrote:

>
> On Tue, 2002-04-30 at 10:17, Michael Mealling wrote:
> > Could you please either explain or point to a discussion that says why it
> > isn't ideal? The Namespaces Rec uses them all over the place and
> > specifically says:
> >
> > "The namespace name, to serve its intended purpose, should have the
> > characteristics of uniqueness and persistence. It is not a goal that it be
> > directly usable for retrieval of a schema (if any exists). An example of a
> > syntax that is designed with these goals in mind is that for Uniform Resource
> > Names [RFC2141]. However, it should be noted that ordinary URLs can be managed
> > in such a way as to achieve these same goals."
>
> I think it may just be that the XML community has sufferered too many
> years of endless what-do-URIs-add-to-namespaces debates since this was
> written.  At its foundation, I think the decision to use URIs
> generically as namespace identifiers was disastrous.
>
> I'm not sure I've seen a canonical explanation of why URNs are evil, but
> you might look at http://rddl.org for some explanation of why more
> transparent approaches are preferable.  To the extent that DDDS and
> similar services can provide RDDL-like information about namespaces
> identified with URNs, my opposition drops.
>
> It might or might not be interesting for the IETF to discuss such
> namespace processing either here or in a separate document.
>
> --
> Simon St.Laurent
> Ring around the content, a pocket full of brackets
> Errors, errors, all fall down!
> http://simonstl.com
>