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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XML Schema built-in data type namespace URI.

Henry S. Thompson wrote:

> Jonathan Borden <jborden@mediaone.net> writes:

> >
> > A big problem here is that QNames and URIs are not being used in a web
> > interoperable or meaningful way. Are you saying that the concept
> > "unsignedInt" as named by
> >
> > http://www.w3.org/2000/10/XMLSchema#unsignedInt
> >
> > is different than the concept "unsignedInt" as named by:
> >
> > http://www.w3.org/2000/10/XMLSchema-datatypes#unsignedInt
> You're crossing threads, Jonathan.  Paul was answering a much simpler
> questions.
> In any case, yes, those two are different, because they are just URI
> references to elements in two distinct XML documents.  Prose in the
> XML Schema Part 2: Datatypes public working draft makes clear that
> these refer to the same builtin simple type definition, but that's in
> the prose, not something which follows from the nature of namespaces.

The resource is the concept "unsignedInt" -- it is useful to refer to this
using a single URI - pick either of the two above.

There is a disconnect between the prose and usage of namespaces and URIs. It
is simplest to use a single namespace and to provide single well-known URIs
for each datatype, regardless of the application that is intended to use the
datatype or URI that identifies the datatype.

I do think it is critical that the W3C identify a single mapping between
QNames and URI references and that this mapping be used in a consistent
fashion across all W3C recommendations. If this isn't done, and quickly,
then as the next generation of recs are built on the current generation of
recs, I fear chaos will ensue.

I consider a QName a shorthand for a URI reference and if I'm using an RDF
application I may wish to refer to something using a QName whereas with an
XLink application an expanded URI reference is more appropriate -- I want
this to be merely a syntactic convention and not have any "meaning" beyond