[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Global/Local attributes

  • To: "Seairth Jacobs" <seairth@s...>,"Uche Ogbuji" <uche.ogbuji@f...>,"David Carlisle" <davidc@n...>,<xml-dev@l...>
  • Subject: RE: Global/Local attributes
  • From: "Dare Obasanjo" <dareo@m...>
  • Date: Thu, 1 Aug 2002 18:12:48 -0700
  • Thread-index: AcI5wP7wnMHlH2RCSN6ftKcH2AY9DQAAJCqA
  • Thread-topic: Global/Local attributes

global local namespace
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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.