Re: name that URI was: Re: RDFCore WG: Datatyping documents

Norman Walsh wrote:


> / "Jonathan Borden" <jborden@mediaone.net> was heard to say:

> |
> | <!DOCTYPE xsd:schema "-//..." [
> | <!ATTLIST xsd:complexType id ID "">
> | ]
> |
> | Now the _baseURI_ is http://example.com/XSD.xsd
> |
> | and the ID is composed as a fragment identifier (well now _assume_ that
> | XPointer is the fragid syntax for application/xml)
> |
> | so the URI would be:
> |
> | http://example.com/XSD.xsd#foo
> |
> | entirely different that what you suspected!
>
> Well, it's true that http://example.com/XSD.xsd#foo identifies the
> element in question, but it's not clear that
> http://example.org/foo-schema-ns#foo does not. That would depend on what
> XML resource the server returned on a request to retrieve the resource
> identified by the URI http://example.org/foo-schema-ns

Sure, but I was careful to identify the base URI. On resolving a different
resource, there would be a different base URI. No?

In any case this example is constructed to point out that how we _want_ XML
Schema qnames to map to URIs, probably isn't how they actually map to URIs
given the current rules of roughly baseURI # ID=fragment identifier. This
issue is more acute when a schema is composed using multiple <xsd:imports>,
in all cases the qname which refers to the XSD type (schema particle) is
namespace qualified by the targetNamespace, not the baseURI of the main, nor
of any of the imported, schemas.

>
> I've never understood the RDF convention of assuming that {uri}#Name
> would identify a resource. A # is a fragment identifier and in the
> absence of a different fragment identifier scheme for RDF documents
> (which would have other problems), the thing that comes after the #
> has to be a name and that name has to be an ID in the document.

The issue is that the RDF definition of "resource" is not the same as the
RFC 2396 definition of "resource". This is indeed confusing. Just as an RFC
2396 resource is something identified by a URI, an RDF resource is something
identified by a URI reference. It's hard to read much more into this.

>
> In particular {uri}#Name could be something entirely different than
> what RDF seems to expect.

RDF does not seem to care what the URI or URI reference resolves to, that is
to say, a resource is what it is defined _by RDF_ to be, not what, for
example, HTTP GET might hint that it is. Well that's the theory. Perhaps
another good issue for the TAG: define a consistent interpretation of the
term "resource" and its relationship to URIs and URI references.

>
> | You argue to proceed. But proceeding without an architectural solution
is
> | what created this mess in the first place. Sometimes  babies need clean
> | bathwater, else an epidemic of cholera.
>
> Indeed. I can see how one could assert that some arbitrary URI was
associated
> with the XML Schema simple type "string",

Indeed XML Schema itself asserts that and provides the URI. XMLSchema.xsd is
careful to follow the rules of URI construction, to the extent that an
internal subset actually defines the "id" attribute on the <xsd:simpleType>
elements as an ID. The only nit is that no fragment id syntax is as yet
defined for application/xml, but I suppose the XPointer WD will have to do
for now.


> but I don't (immediately) see how
> that could be extended to the subtype my:string defined in my schema, and
I
> imagine we want to enable both.
>

I'd hope so, because limiting ourselves to the set of predefined XML Schema
primitive types is well, boring.

Jonathan

Received on Wednesday, 30 January 2002 20:45:27 UTC