Cart
|
[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: Enlightenmentvi
 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@j...> To: "Fuchs, Matthew" <matthew.fuchs@c...>; "'Jonathan Borden'" <jborden@m...>; <xml-dev@l...> 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> > > 
|
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
|
|||||||||
