ietf-mxcomp
[Top] [All Lists]

RE: suggested new RRtype experiment

2004-05-22 10:45:30

Doug,

I'm having a hard time understanding what you're saying. Let me run a
couple of interpretations past you and see if either of them matches
your intent.


Interpretation 1:

You said (through my paraphrase):  Yes, if we use XML we need a
namespace, and that needs a URI. But we shouldn't use an HTTP URI, we
should use a value-neutral one like an IETF URI.

My response: Yes, it would be possible to do that. It means that our
namespace would be something like "ietf:rfc:9999".


Interpretation 2:

You said (through my paraphrase):  No, we don't need no stinkin' URI's.

My response: I believe that you're mistaken.


I'm hoping that you intended #1. If not, please try again.

-- jimbo


-----Original Message-----
From: Douglas Otis [mailto:dotis(_at_)mail-abuse(_dot_)org] 
Sent: Friday, May 21, 2004 10:25 PM
To: Jim Lyon
Cc: Bob Atkinson; Eric A. Hall; Arnt Gulbrandsen; Yakov Shafranovich;
IETF MARID WG
Subject: RE: suggested new RRtype experiment

On Fri, 2004-05-21 at 17:57, Jim Lyon wrote:
Doug,

I fear that there may be some things that you misunderstand about XML
namespaces and schemas.

Jim,

This is not for a web page and the protocol is not HTTP.  The name space
(token) is controlled by the relevant DNS specification.  A URI is not
needed for this purpose.

Every (and I mean EVERY) XML namespace and schema is identified by a
URI. The URI contains no semantic information, but serves entirely to
disambiguate the identifiers.

If you must use XML, create a document template and define this as a
token in the standard.  IANA has a registry for this.  There is no need
to use a URI such as http://cid-xml.microsoft.com/marid to serve as this
token.  None.  MARID-1 is fine.  The danger of using a URI for this
purpose is clear.  It allows anyone, such as yourself, to think they
have license to publish any such definitions.  This is not just another
web page, this is not HTTP, it is DNS.  It must be clear, this is not
how definitions change.

Think of it as a distributed collision-avoidance mechanism. It is
traditional to use HTTP URLs as these URIs, and to ensure that the
use is done with the blessing of the owner of that position in the
HTTP name space.

Effects are not limited to just the owner of the name space.  This
impacts EVERY pre-compiled parser that will then need to pull in new
definitions.  

An XML Schema, once published, is forever immutable. (Yes, I mean
forever.)

Immutable aspect of files is completely unimportant.  Their names will
be left in the dust.  Changes to these definitions should not be the
prerogative of a programmer with a desire to publish a new version. It
will impact the stability of code needing a predefined template.  That
template should not change without it being reflected in a standard.  To
wrest control back into the standard, this MUST not be a URI.  This is
not a difficult concept and it even saves precious space as further
justification.

You don't get to revise it, period. If you later need extensions, you
publish them in a new name space with a new XML schema.

Exactly. This is a problem. Plugging in a new schema demands that the
new schema be read.  This could be sent by Pony Express, but that would
not change the need to read the definition.  If this were HTTP, it would
not be a problem.  This is DNS however.  

So, the contents of the schema can certainly be baked into code. It is
never necessary for someone interpreting the schema to use HTTP and
fetch data. There is no requirement that people who publish schemas
maintain HTTP servers that answer that URL. (Many do, but only as a
courtesy to humans who are wondering what the URI means.)

It is not humans in this case wondering.  It is a system that will stop
functioning.  Ad hoc will not work and can not be tested.  Get rid of
the URI.  It is a calamitous mistake.

-Doug