[
Lists Home |
Date Index |
Thread Index
]
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@seairth.com]
> Sent: Thursday, August 01, 2002 6:08 PM
> To: Uche Ogbuji; David Carlisle; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] 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@seairth.com
>
>
>
> From: "Uche Ogbuji" <uche.ogbuji@fourthought.com>
> > > >
> > > > > 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>
|
