[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Global/Local attributes
What is broken is the existence of a default namespace. Further mangling Namespaces in XML to accomodate this mistake is unwise and borders on foolishness. -- PITHY WORDS OF WISDOM Never be the boss' right hand man if he's left handed. This posting is provided "AS IS" with no warranties, and confers no rights. > -----Original Message----- > From: Seairth Jacobs [mailto:seairth@s...] > Sent: Thursday, August 01, 2002 6:08 PM > To: Uche Ogbuji; David Carlisle; xml-dev@l... > Subject: Re: Global/Local attributes > > > Since we are all getting confused and since we are proposing > a change in the way that certain attributes are handled when > namespaces are involved, how abou this... Suppose the following XML: > > <elem1 xmlns="http://example.com/ns1" > xmlns:x="http://example.com/ns2"> > <x:elem2 x:attr1="" attr2="" /> > <elem3 attr3="" /> > </elem1> > > In the above, we know the following to be true according to > the current rec: > > elem1 belongs to the default namespace > ("http://example.com/ns1"). elem2 belongs to the "x" > namespace (="http://example.com/ns2"). attr1 belongs to the > "x" namespace. attr2 belongs to no namespace at all. elem3 > belongs to the default namespace. attr3 belongs to... > default namespace or no namespace? ("Note that default > namespaces do not apply directly to attributes." [1]) > > According to the rec, I would have to say that "attr3" > belongs to no namespace. > > Now, I hear what Simon has been saying. And I know (I think) > that he is mostly talking about the instance where you could > have something like: > > <elem1 xmlns="http://example.com/ns1" > xmlns:x="http://example.com/ns2"> > <x:elem2 x:attr="" attr="" /> > </elem1> > > However, I would think that in the case above that "attr2" > should belong to the default namespace, not the namespace > that "elem2" belongs to. The reason for this is that there > is no other way to use attributes defined in the default > namespace. If you want, you could have a fall-back rule that > says a non-prefixed attribute would belong to no namespace if > a default namespace is not defined. However, I think a rule > like that would would reduce readability and be more error-prone. > > > > So, how about the following instead: > > <:elem1 xmlns="http://example.com/ns1" > xmlns:x="http://example.com/ns2"> > <x:elem2 x:attr1="" attr2="" /> > <:elem3 attr3="" /> > <elem4 :attr4="" /> > </:elem1> > > elem1 belongs to the default namespace. > elem2 belongs to the "x" namespace. > attr1 belongs to the "x" namespace. > attr2 belongs to no namespace. > elem3 belongs to the default namespace. > attr3 belongs to no namespace. > elem4 belongs to no namespace. > attr4 belongs to the default namespace. > > > At this point, everything is explicit, even the use of > elements and attributes in the default namespace. I agree > that this still means that "attr2" does not belong to the > namespace of "elem2". However, I think it's fair to say that > there may be a valid reason for this construct. For > instance, someone might want to augment an existing namespace > locally. In fact, we tend to refer to elements/attributes > that are not in a namespace to be global. In reality they > are only global to that document, while they are actually > local in the sense of namespaces. > > Now, if you look back at: > > <elem1 xmlns="http://example.com/ns1" > xmlns:x="http://example.com/ns2"> > <x:elem2 x:attr="" attr="" /> > </elem1> > > the question is: does this help the situation where the > "attr" localname is used more than once in the same element? > To me, the answer is yes. Someone could look at: > > <:elem1 xmlns="http://example.com/ns1" > xmlns:x="http://example.com/ns2"> > <x:elem2 x:attr="" attr="" :attr=""/> > </:elem1> > > and know exactly what each of the "attr" attributes belong > to. Does it make for good readability? I suppose that > depends on the actual instance... after all, you may have > something like the following: > > <:elem1 xmlns="http://example.com/ns1" > xmlns:x="http://example.com/ns2"> > <x:elem2 x:processelement="yes" processelement="no" > :processelement="yes"/> </:elem1> > > Where "processelement" may be used to allow processors that > are aware of different namespaces to conditionally pay > attention to a certain element. In this case, a processor > that understood the "http://example.com/ns2" namespace would > process "elem", a processor that understood these local > documents would not process "elem", and a processor that > understood the "http://example.com/ns1" namespace would > process "elem". > > A stronger example might be that namespace information is > added to a document in a pipeline such that the original > document is not fundamentally altered. For instance, suppose > you had a stage that understood a specific document type. > Let's say that an element in the XML looks like: > > <price type="currency" separator="," decimal=".">1.00</price> > > Now, the job of this stage is to preprocess the document and > add additional information that will be understood be a > future stage. Now, the future stage is looking for specific > attribute names (which are local to the pipeline only). Not > too surprisingly, those names are the same as those in the > original document. As a result, the current stage qualifies > the current XML with a namespace to avoid confusion (yes, I > know you could do it the other way round if you have complete > control of the pipeling, but let's assume that you are only > responsible for writing this stage and have no choice about > what should ideally be given to the future stage). So, when > this stage spits the XML out to the next stage, it looks like: > > <x:price xmlns:x="http://example.com/ns3" > x:type="currency" x:separator="," x:decimal="." type="float" > decimal=".">1.00</price> > > At this point, we have the same exact localname being used > more than once for very legitimate reasons (imho). In fact, > I think this scenario is going to be increasingly likely as > we begin to pass our XML documents around and allow each > handler of the document to throw their own additional > elements and attributes into the mix. By the time you > receive the document (after it has been passed all over the > place, been dropped on the floor a few times, and washed off > with flat soda water)... > > Now wait... I think I have gone a bit off track here... so may just a > summary: > > 1) I propose the above change to the Namespace rec (in version 2?). > 2) Assuming #1 comes about, then anything that is not > qualified belongs to the "global" local non-namespace. > Always. Even if the same localname is used more than once in > the same element and one of the attributes is in that non-namespace. > > > [1] http://www.w3.org/TR/1999/REC-xml-names-19990114/#defaulting > > > --- > Seairth Jacobs > seairth@s... > > > > From: "Uche Ogbuji" <uche.ogbuji@f...> > > > > > > > > > Then according to the rule we're proposing, nothing > significant > about > > > > > the attribute has changed at all. The namespace, > which is the > > > > > important matter, is the same. > > > > > > > > so now I'm confused. It seems to me you are proposing > that in the > > > > first, unprefixed, case the namespace of the attribute would be > > > > (or could be considered as) the namespace of the element > > > > (associated with the prefix x:) which is not the same as the > > > > current interpretation. > > > > > > You managed to spread your confusion to me, it seems. By "the > > > current interpretation", do you mean XML Namespaces 1.0? > > > > Wait a minute. I think (hope) the source of confusion just > occurred > > to > me. > > > > I have used the term "global" in two ways in this thread. > At first I > > was using it according to its current definition in XMLNS > 1.0. When > > we > started to > > discuss an alternative interpretation of unprefixed > attributes, my use > > of > the > > term actually changed to match my preference for the alternative. > > Rather > than > > using "global" to mean any prefixed attribute, I started using > > "global" to mean any attribute outside the namespace of its parent. > > > > If so, my fault. It should have occurred to me that this would sow > confusion. > > I'll try to be careful to use the term "foreign > attributes" to mean > > attributes in foreign namespace. Of course, this puts me > at a slight > > disadvantage because one of my points has been that treating > > unprefixed > attrs > > as being in their parents' namespace would actually lead to a more > > logical following of the normal use of the term "global" in > > discussions of > technical > > scoping. > > > > ----------------------------------------------------------------- > 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 list 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
|