[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Suggested guidelines for using local types. (was Re: Enlightenment v
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|