OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] URIs harmful (was RE: [xml-dev] Article: Keeping pace with

[ Lists Home | Date Index | Thread Index ]

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
even usable.

We would be interested in hearing whether this sounds sensible, and if there
are any landmines along this path...

Thanks,

Mark
 

 -----Original Message-----
From: 	Simon St.Laurent [mailto:simonstl@simonstl.com] 
Sent:	Monday, July 22, 2002 9:51 AM
To:	xml-dev@lists.xml.org
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
repeatedly.)

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
bizarre.

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.
-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com

-----------------------------------------------------------------
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
manager: <http://lists.xml.org/ob/adm.pl>




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS