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: RDDL: Namespace URIs as document types. was Re: URIs,names and well known RDDL names

>     I think in many many cases and in particular formats such as
> XML Schema,
> the namespace URI, the xlink:arcrole and the xlink:role can be equal,

By being equal, are you saying that both arcrole and role have the value
http://www.w3.org/2000/10/XMLSchema? I don't understand how that would be

> because there will mostly be a single resource of a single format
> associated
> with a namespace URI (e.g. only one XML Schema, only one
> Schematron schema,
> only one RDF Schema and only one TREX Schema), so there is a need for only
> one name for a link and the namespace URI of the resource is a good one.

I'll grant you that this will most often be the case (as far as I can
envision it) but unless we're explicitly disallowing multiple resources of
the same type than we need a more formal definition of how that's to be
specified and processed.

>     Actually the *type* of a namespace'd document is more
> properly the pair
> of the namespace URI and the root element name, e.g.:
>     {namespaceURI, documentElement}
>     {"http://www.w3.org/2000/10/XMLSchema","schema"}
>     {"http://www.ascc.net/xml/schematron","schema"}
>     {"http://www.xml.gr.jp/xmlns/relaxCore","module"}
>     The most reasonable way to represent this as a URI, IMHO, is to
> concatenate the namespace URI with the root element name as a fragment
> identifier e.g.
>     http://www.w3.org/2000/10/XMLSchema#schema
>     http://www.ascc.net/xml/schematron#schema
>     http://www.xml.gr.jp/xmlns/relaxCore#module

I don't think this is a good idea at all. It may work for the examples you
cited but I can think of several that break it.

Look closely at the grammar for RDF. The rdf:RDF element is optional [1].
That implies that any element from any namespace (using the typed node
production) could be the document element for an RDF document.

XSLT allows the "literal result element as stylesheet" syntax [2] in which
the document element can be any element from any namespace (though usually
html). Additionally, when using the "normal" syntax, either xsl:stylesheet
or xsl:transform is allowed as the document element.

TREX [3] offers even more choices for deciding on what document element to
use. Even the namespace URI is optional!

> This spec is intended to be simple and it should be simple for people to
> understand. Since I'm confused about what the role of xlink:role vs.
> xlink:arcrole ought be, we need work on clearly defining these issues and
> recommended practices.

I think that we basically agree here. The simplest, workable solution that I
can imagine is using simple URIs.

xlink:role can be used to identify the "semantic type" of the resource. This
should be a URI and, in fact, has to be. XLink requires that both role and
arcrole be absoulute URIs [4].

If there exists some URI that could reasonably be assumed to identify one of
these "semantic types" then it should be used. Perhaps even "blessed" by
RDDL by including it in some roles.html file. I think that we would all
agree that http://www.w3.org/2000/10/XMLSchema could reasonably be used to
identify XML Schema documents. But that http://www.w3.org/1999/xhtml does
not reasonably identify a RDDL document (despite a RDDL document's document
element). This is a judgement call that somebody has to make--I say we let
the authors of each spec get the first crack at it.

If a type isn't serialized as XML and so doesn't have a namespace URI or
something that we could all reasonably agree upon, then somebody needs to
make one up for it. How about http://www.rddl.org/mime/application/zip, for
example? Or, better, urn:Content-Type:application/zip. I don't really care
what the specific URI is as long as it's documented and we all use the same

To me this is as simple as it gets and doesn't require any inferring of type
based on document content which you already pointed out was unreliable.