Re: Suggested guidelines for using local types. (was Re: Enlightenmentvia avoiding the T-word)

[Peter Piatko <piatko@research.telcordia.com>]

I am starting to have a different view of namespaces which, while perhaps
not really answering any questions, simplifies my conception of namespaces
because is disassociates namespaces from "meaning."  As you have shown, it
is inherently a fuzzy concept.  Also, there's a difference between namespace
as an idea, and the syntax as given in the W3C Namespace recommendation.  I
think most of the argument is really about the latter.  Here's my current
view, which is probably full of holes.  ;-)

NB: All of this is qualified by, "IMHO".  ;-)  None of this is in the
Namespace recommendation, which leaves a lot open to interpretation.

1) Conceptually at least, all *labels* belong to some namespace (local and
global element and attribute labels are treated no differently).

2) A URI is a pointer to a namespace.  If at some point during my processing
of an XML instance, I can associate a namespace URI to a label, then let's
say that the label is "namespace qualified."  (This may be different from
the way the W3C Namespace rec defines it).  Note: If during processing I
can't associate a namespace URI with a label that does *not* imply it
doesn't belong in a namespace.

3) Assume there exist functions such that function(URI, label) = URI'.  Then
we can have "Per Element Type Partitions" as described in the Appendix of
the Namespace recommendation---i.e. create a function attributeNS(), so that
attributeNS (URI, element label) is the namespace for the attributes for
that particular element label.

4) We can do the same for local elements, although the trick is to use the
label for the complexType (not the parent element)---i.e. local-elementNS
(URI, complexType label) = URI'.

We can come up with all manner of  functions.  They are essentially just
agreed upon conventions for mapping between different namespaces (this is
sort of like multiple pointer dereferencing).

Following this logic, it would be nice if all labels were "namespace
qualified."  Note that *unprefixed* attributes are in my view for all
practical purposes namespace qualified if their associated element label is
also qualified (since I can retrieve the URI through my attributeNS()
function).

The problem with local elements is that the existing syntax doesn't handle
them well.  XSDL currently gives you two choices (1) unqualified = the
instance won't tell you what namespace the local elements belongs ...
although if the processor is schema aware, it can "qualify" them or (2)
qualified = local element labels belong to the target namespace of the
schema ... i.e. a particular label can have multiple "meanings" (which is
fine from a namespace's POV, which deals with labels and not meanings).

From a instance reader's perspective there are problems with either choice.
Much of the recent discussion has finally revolved around how to fix it by
(1) deciding on an appropriate namespace for local elements and (2) deciding
on an appropriate syntax for doing correct qualification in instance
documents.

FWIW, since I don't feel that the current syntax handles XSDL local elements
very well, I think the default best practice is to simply avoid them for the
moment.

Thanks,

Peter

----- Original Message -----
From: "James Clark" <jjc@jclark.com>
To: "Fuchs, Matthew" <matthew.fuchs@commerceone.com>; "'Jonathan Borden'"
<jborden@mediaone.net>; <xml-dev@lists.xml.org>
Sent: Wednesday, September 05, 2001 10:45 PM
Subject: RE: Suggested guidelines for using local types. (was Re:
Enlightenment via avoiding the T-word)


> Not everybody seems to be answering the same question here.  We can
> distinguish the questions:
>
> (a) If the meaning/allowed content of an element is highly
> context-dependent, should the name of the element be namespace qualified
or
> not?
>
> (b) If an element is declared by an XSL local type, should the name of the
> element be namespace qualified or not?
>
> >From my perspective, question (a) is the primary question, and although
XSD
> may be relevant, it's not an XSD-specific question.  It's a namespaces
> question.  It arises equally if you are using RELAX NG to define your
> vocabulary.  People who view XSD as the center of the XML universe may
view
> (b) as the primary question.
>
> My answer to (a) would be that it should be namespace qualified. Here's
> why.  I don't see a sharp, binary distinction between context-dependent
and
> context-independent elements; rather I see a continuum of different
degrees
> and kinds of context-dependence.  For example,
>
> 1. At the most context-independent end of the spectrum, we have an element
> like <html> which occurs only as the root element.
>
> 2. Another step down, would be something like <h1> which cannot occur as a
> root, but has consistent content model and processing wherever it occurs.
>
> 3. Another step down, would be something like a <title> element that can
> appear as the child of a <chapter>, <section> or <subsection>.  It has the
> same content model, but the processing may partly depend on the context.
>
> 4. Another case would be an element subject to SGML exceptions. Say a
> <para> make occur inside or outside a <footnote>, but inside a <footnote>
a
> <para> may not contain a <footnote>.  In a DTD, you would not be able to
> express the distinction. In RELAX NG, you would use a separate pattern for
> the content of a <footnote> in a <para>
>
> 5. Further towards the context-dependent part of the spectrum, would be
> something like <param> in HTML; it is allowed by both <object> and
<applet>
> with a consistent semantic, but it doesn't make any interpretation outside
> its containing <object> or <applet>.
>
> 6. I guess the most context-dependent would be something like
> thead/tbody/tfoot which occur only in a table.
>
> I don't see any point on this continuum where it makes sense to draw a
line
> and say: above this line namespace-qualify, below this line don't
> namespace-qualify.
>
> I would suggest instead that the question of whether to namespace qualify
> should be based on the answer to the question: what is the namespace that
> defines the meaning of this element? If there is such a namespace, then
the
> name of the element should be qualified with that namespace. If there is
no
> such namespace, then then name of the element should not be
> namespace-qualified.
>
> As for attributes, I would say that the attribute should be namespace
> qualified if (and arguably only if) the meaning of the attribute is not
> determined by the namespace of the parent element.  This implies that the
> name of the attribute that extends the attributes of a namespace-qualified
> element should be namespace qualified.  This seems a natural guideline to
> me. (I think it corresponds to what ##other does in XML Schema for
> anyAttribute.)
>
> One objection to this is that it is not uniform between elements and
> attributes. My response would be that this non-uniformity is appropriate
> given that this is primarily a namespaces issue, and given that the
> Namespaces Rec does not default namespaces uniformly for elements and
> attributes.
>
> James
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>