[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Suggested guidelines for using local types. (was Re: Enlightenment via avoiding the T-word)
- From: James Clark <jjc@jclark.com>
- To: "Fuchs, Matthew" <matthew.fuchs@commerceone.com>,'Jonathan Borden' <jborden@mediaone.net>, xml-dev@lists.xml.org
- Date: Thu, 06 Sep 2001 09:45:25 +0700
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