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: 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