[
Lists Home |
Date Index |
Thread Index
]
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.
|
