[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XML Schema built-in data type namespace URI.
- From: Jonathan Borden <email@example.com>
- To: "Henry S. Thompson" <firstname.lastname@example.org>
- Date: Thu, 08 Mar 2001 13:51:16 -0500
Henry S. Thompson wrote:
> Jonathan Borden <email@example.com> 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
> 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