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


Help: OASIS Mailing Lists Help | MarkMail Help



   schemas and namespaces

[ Lists Home | Date Index | Thread Index ]
  • From: "Simon St.Laurent" <simonstl@simonstl.com>
  • To: "David E. Cleary" <davec@progress.com>, <xml-dev@xml.org>, <xml-uri@w3.org>
  • Date: Fri, 19 May 2000 12:03:38 -0400

At 11:53 AM 5/19/00 -0400, David E. Cleary wrote:
>The Schema WG is not advocating that schemas be pointed to by namespace
>URIs. That is what the SchemaLocation attribute is for. Do not confuse the
>opinions of some as the consensus of the Schema WG.

I'm glad to hear that there is no consensus.

>> This activity is a large part of what makes the relative URI discussion so
>> ugly, because the results of that are intertwined with the
>> NSURI-pointing-to-schemas issue.
>That is a red herring IMHO. The issue is that Namespace, XPath, and DOM recs
>are inconsistent with their use of NS URI equivalence. There is currently no
>rec stating what an application can or can't do with a namespace URI.

It may be a red herring technically, but it seems to be a key driver behind
the discussion - in particular regarding why relative namespace URIs might
be useful.

>Decide what rec needs to be changed and do it is such a way that doesn't
>break currently conforming documents. Leave the packaging and dereferencing
>out of it for now.

I'd be happy with that, provided the other issues are (finally) taken up.

>Since there is currently no specification as to what resides at the endpoint
>of a NS URI, shouldn't it be up to the owner of that URI to decide what is
>there? The fact is that in many real applications, schemas will not
>retrieved over the web to process an instance document. They will be stored
>and retrieved locally based on the NS URI. But again, this has nothing to do
>with solving the problem at hand.

Yes, but the W3C is no ordinary owner of a URI - they're a body defining
said specs, and it's clear from discussion that this is not an arbitrary
"we can do what we like" decision.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth

This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/


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

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