RDDL: Namespace URIs as document types. was Re: URIs,names and well known RDDL names

[Jonathan Borden <jborden@mediaone.net>]

Henry S. Thompson was:

>..Software should use xlink:role to identify
> the namespace of the destination resource.  In cases where more than
> one destination resource with the same xlink:role is offered,
> xlink:arcrole disambiguates.
>
    Firstly note that I have updated http://www.rddl.org/arcrole.htm to
reflect the fact that the well-known name for XML Schema *is*
http://www.w3.org/2000/10/XMLSchema (at least until the .../2001/... version
comes out :-)

    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,
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.

    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

    Now unfortunately  *none* of these brings me to any prose documentation
but that's another story...

    So as a type, using a namespace URI is very close to being correct,
according to the notion of type as defined in XML Schema and RDF Schema. The
problem as I see it is that using this type of language is in danger of
confusing people. In particular the XML 1.0 specification talks about
"document type definition" in a different way, and for non-XML documents the
closest we get to types are through NOTATIONs which aren't widely used and
MIME types.

    Yet even using the root element namespace URI, the document type is not
clear. For example RDDL itself, which we define as an extension to XHTML
Basic. All XHTML derived languages use http://www.w3.org/1999/xhtml#html as
a {namespace URI,root element} and on one hand a RDDL document *is* XHTML,
on the other hand its function as a resource in a RDDL document (currently
undefined) would not merely be an XHTML page.

    For the situation where a namespace URI points to a fixed resource,
however, the assumption is that the document type is determined by the root
namespace URI (+ perhaps element name) and in this case there's no issue
with dispatching because there's only one way to go... in such cases we
could define the 'virtual' xlink:role and xlink:arcrole to be the same and =
namespaceURI (+root element).

    If we:

a) define namespace URI == document type
b) define this as the primary dispatch value

I see problems in these areas:

1) We still need a dispatch mechanism for non-XML documents and the non-XML
document type "content-type" doesn't work.

2) XHTML Basic (assuming that certain devices such as PDAs will have
specific versions of documents in XHTML Basic). It is easiest to refer to
two resources as "XHTML 1.x" and "XHTML Basic" --- and if we are defining
xlink:role as == root namespace URI, then xlink:arcrole is the value most
people are interested in.

3) Confusion/conflation with the an XML 1.0 "document type", we'd spend
countless hours explaining that this is an XML Schema type not a DOCTYPE.
(Note using DOCTYPES to dispatch is not an option because these are optional
and not even recommended for many document types we are concerned with).

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.

-Jonathan