RE: Thoughts on namespaces

Regarding the proposal to make schema references a special kind of link,
I applaud the intention of seeking unification where ever possible, but
on this particular application I conclude that the attempted unification
is the opposite of what is needed. A namespace import frequently
contains a link, but is not a link.

With thanks to James Clark for clarifying these distinctions to me,
there are three issues that need to be solved when introducing
namespaces:

1.	Signalling what namespace an element type is in (the colon
stuff).
2.	Giving the element a precise name, in the IETF URI namespace.
(This is the principal function of the URI of the namespace. It not only
gives a precise name to the space, but locates every element name within
that space as a URI itself.)
3.	Linking to the schema or whatever defines the namespace. (A
document, possibly at an entirely different address than the URI of
issue 2.)

Actually, only the first two are needed to disambiguate names and
integrate them into the IETF naming system. The third (reference to a
schema doc) is an additional feature that permits all of the useful
things that DTDs support, such as validation.  The first two are
necessary for a well-formed document with namespaces; the third is
needed to validate it.

So, the crucial issue is not a link to an external document, but
association of a namespace's local name (short prefix) with a full URI
delimiting a region of URI space.

This is not, per se, a link to an external document. In fact, there may
not be an external document.

Consider also the precedent this would set.  In effect, this proposal
says: "Here is a reference to a point in URI space.  It shares some
characteristics with links in general, such as that they both contain
URIs, they both have attributes, etc. This one has particular semantics.
So, let's capture the semantics with a series of special attributes of
the link." By that reasoning, any element that has some characteristics
of a link, including merely containing a link, should instead be
expressed as a link with reserved attributes. This spreads the non-link
information over several attributes, making management difficult since
it breaks what is conceptually a single unit into an un-validatable
collection of attributes (unvalidatable in the sense that no DTD can
express anything but the most primitive rules for their presence). Nor
is it generally extensible:  What is the extensibility mechanism if we
discover in six months that a namespace import needs more information,
and that information is structured and thus cannot be expressed as an
attribute. What is the mechanism by which authors could add their own
link types, with validation?

Finally, and to return the the point that a namespace is not a link to a
document, we see from an XML document's InternalSubset of the DTD the
necessity of having certain schema information in the document, not in
an external resource. Given that we value having validatablity, we will
want this DTD information, not all of which is always external. Phrased
differently, a namespace's definition (DTD) will frequently, but not
always, contain all its contents in an external file. Sometimes vital
contents will be inline.  A namespace import frequently contains a link,
but is not a link.

--Andrew Layman
   AndrewL@microsoft.com

> -----Original Message-----
> From:	Tim Bray [SMTP:tbray@textuality.com]
> Sent:	Tuesday, June 03, 1997 5:19 AM
> To:	w3c-sgml-wg@w3.org
> Subject:	RE: Thoughts on namespaces
> 
> All of the namespace proposals have to solve two problems:
> 
>  1. linking to the schema or whatever defines the namespace, and
>  2. signalling what namespace an element type is in (the colon stuff).
> 
> For #1, we've had proposals for using elements and PI's and weird new
> marked section-like syntax.  Despite the fact that the problem has
> "link" in its name.  This could obviously done with xml-link given
> a reserved role like 
> <x XML-link="extended" role="xml-namespace" href=".."
> short-prefix=".."/>
> 
> Given that it can be, it should be.  Why not? -Tim
>

Received on Tuesday, 3 June 1997 13:49:17 UTC