Lists Home |
Date Index |
I probably should have put the message below under my original subject line.
It was triggered by our thinking on the use of a URL as a schemaLocation
hint and also as a namespace name (forgot to mention the latter in my
message). The URI/URL/URN debate is lost on me as a practitioner. I'm
trying to figure out the ramifications of using them in practical, evolvong
schema sets, both in the namespace name and the schemaLocation.
From: Mark Feblowitz
Sent: Monday, July 22, 2002 10:35 AM
To: 'Simon St.Laurent'; firstname.lastname@example.org
Cc: Duane Krahn (E-mail); Satish Ramanathan (E-mail); Andrew Warren
(E-mail); Kurt A Kanaskie (Kurt) (E-mail); Mark Feblowitz; Michael Rowell
Subject: RE: [xml-dev] URIs harmful (was RE: [xml-dev] Article:
Keeping pace with James Clark)
From a practitioner's point of view, I need to determine conventions for
naming the namespace of my schemas, for defining the schemaLocation hint,
and for establishing a version.
Our current consensus looks to be the following:
The namespace name will be generic and version free, and will only change if
the language changes *very significantly*. That's because we expect
too-frequent changes in our quasi-canonical language, and expect the
alternative - too-frequent namespace changes - to be too big of a burden on
our hundreds of user/developer teams.
The schemaLocation hints will be full URLs, with the expectation that all
performance-savvy parties will cache for these URLs. For those who prefer
not to do "proper" caching, they can strip off the first few parts of the
URLs and induce their own schemaLocations from the full URL hints.
The version number will be kept in a version attribute in each instance
document, to be matched upon processing. Depending upon our as-yet unreached
consensus, we may or may not fix the version attribute and have the
validating parsers reject or accept version mismatches. (Leaning toward
rejecting mismatches). It would be interesting to have support in Schema for
a version equivalents list, but I suspect that it would rarely be used or
We would be interested in hearing whether this sounds sensible, and if there
are any landmines along this path...
From: Simon St.Laurent [mailto:email@example.com]
Sent: Monday, July 22, 2002 9:51 AM
Subject: Re: [xml-dev] URIs harmful (was RE: [xml-dev] Article:
Keeping pace with James Clark)
> "Simon St.Laurent" wrote:
> What concrete interoperability problems (as opposed to overheated,
> never-ending discussions) have you experienced in a specification
> using the term URI rather than URL? Yes, the situation is confusing,
> and confusion is a problem. But interoperability problems are a
> separate issue and I have not seen many of those.
I've run into a few different levels of interop problems:
1) Developers who can't even figure out how the URI side of things works
and can't find vocabulary to talk with each other about it. (This level
of frustration seems mostly ignored here since we've all talked it to
death.) Many of these people say screw it and simply use the QName as
an identifier, ignoring the URIs completely. This produces much simpler
code that works - up to a point. (Yes, I've since this in the wild, and
2) Developers who build applications for local systems where they have
complete control over how a URI gets processed (heck, throw an XPointer
on the end of a URN!) who are then unpleasantly surprised if their
documents ever have to be processed in a different environment.
3) Developers who put something at the end of that URI, typically a
schema, thinking everyone else does it, only to find that other people
think their documents are weird, but that incoming documents are also
Sure, experts on namespace can sort this all out. Does that mean the
spec made sense in the first place? How many experts does it take to
get namespaces right? The only genuinely surprising thing to me about
namespaces is that we've put up with this for so long.
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription