=0A=
=0A=
Noah,=0A=
thank you for your answer. =0A=
=0A=
 =0A=
=0A=
>=0A=
<!-- prefix p and the default are bound to the same namespace URI =0A=
> -_>=0A=
> <outer xmlns="http://example.org/ns" =0A=
> xmlns:p="http://example.org/ns">=0A=
> <-- no duplicate attribute error in the following -->=0A=
> <inner a="1" p:a="2"/>=0A=
> <-- the following has the same element tag as the one above -->=0A=
> <p:inner />=0A=
> </outer>=0A=
=0A=
 =0A=
=0A=
I=0A=
see that your example presents a valid piece of XML, but I believe there ar=
e=0A=
other =96 more readable - ways to have two attributes with the same name in=
 one=0A=
element. I believe the XML in your example leads to confusion, as to which=
=0A=
namespace the attributes belong, especially because elements don=92t need a=
=0A=
prefix to indicate they belong to the target namespace, whereas attributes =
do.=0A=
At first sight, one would think that both =93a=94 and =93p:a=94 belong to t=
he same=0A=
namespace (the same that is also associated with the =93inner=94 and =93out=
er=94=0A=
element), whereas actually the first occurrence of =93a=94 does not belong =
to a=0A=
namespace at all. Wouldn=92t it be more intuitive and improve readability t=
o have=0A=
both of the attributes in a different namespace, instead of one attribute b=
eing=0A=
in no namespace? =0A=
=0A=
 =0A=
=0A=
Let=92s=0A=
say, if the default namespace would apply to attributes, the following two=
=0A=
examples would represent the same thing, i.e. the =93p:a=94 would be equal =
to the=0A=
=93a=94.=0A=
=0A=
 =0A=
=0A=
Example=0A=
1=0A=
=0A=
---------=0A=
=0A=
<!--=0A=
prefix p and the default are bound to the same namespace URI -->=0A=
<outer xmlns="http://example.org/ns" =0A=
      =0A=
xmlns:p=http://example.org/ns=0A=
=0A=
       xmlns:q=http://example2.org/ns>=0A=
  <-- no duplicate attribute error in=0A=
the following -->=0A=
  <inner p:a="1" q:a="2">=0A=
  <-- the following has the same=0A=
element tag as the one above -->=0A=
  <p:inner />=0A=
</outer>=0A=
=0A=
 =0A=
=0A=
Example=0A=
2=0A=
=0A=
---------=0A=
<!-- prefix p and the default are bound to the same namespace URI -->=0A=
<outer xmlns="http://example.org/ns" =0A=
      =0A=
xmlns:p=http://example.org/ns=0A=
=0A=
       xmlns:q=http://example2.org/ns>=0A=
  <-- no duplicate attribute error in=0A=
the following -->=0A=
  <inner a="1" q:a="2">=0A=
=0A=
  </inner>=0A=
</outer>=0A=
=0A=
 =0A=
=0A=
Nevertheless,=0A=
per [1] attribute =93a=94 in Example 2 does not belong to same namespace as=
 =93p:a=94=0A=
in Example 1, thus the examples do not represent the same thing. =0A=
=0A=
 =0A=
=0A=
>=0A=
Reading between the lines, the Namespaces recommendation takes the view =0A=
> that attributes tend to be scoped to the elements on which they appear. =
=0A=
=0A=
=0A=
=0A=
I saw=0A=
this statement as well, but to me it does not provide sufficient rationale =
for=0A=
not applying the default namespace to attributes.=0A=
=0A=
 =0A=
=0A=
>=0A=
Also, it's quite common in colloquial XML usage, to find unqualified =0A=
> attributes on qualified elements.=0A=
=0A=
 =0A=
=0A=
Probably,=0A=
this is because normally one doesn=92t really notice the difference and as =
long=0A=
as a document validates, many people don=92t think about it. It only become=
s=0A=
clear when you start referencing them (e.g using =93key=94 and =93keyref=94=
) and see=0A=
that the document does not validate if you use a prefix both for the elemen=
t=0A=
and the attribute (because the attribute does not belong to the same namesp=
ace).=0A=
=0A=
 =0A=
=0A=
XML=0A=
Schema snippet=0A=
=0A=
------------------=0A=
=0A=
<xs:element=0A=
name==94inner=94 type==94innerType=94>=0A=
=0A=
  ....=0A=
=0A=
  <xs:attribute name==94a=94 type==94aType=94/>=0A=
=0A=
</xs:element>=0A=
=0A=
 =0A=
=0A=
XML=0A=
instance snippet (INVALID)=0A=
=0A=
------------------------------=0A=
=0A=
<xsd:keyref=0A=
refer="key" name="keyRef">=0A=
=0A=
  <xsd:selector xpath=".//p:inner"/>=0A=
=0A=
  <xsd:field xpath="@p:a"/>=0A=
=0A=
</xsd:keyref>=0A=
=0A=
 =0A=
=0A=
In=0A=
summary I would say that your answer has not yet convinced me and I look=0A=
forward to continuation of the discussion.=0A=
=0A=
 =0A=
=0A=
Best=0A=
regards,=0A=
=0A=
Nanda=0A=
=0A=
 =0A=
=0A=
[1] http://www.w3.org/TR/REC-xml-names/#uniqAttrs=0A=
=0A=
> To: nandakol@h...> CC: xmlschema-dev@w...> Subject: Re: Why does=
 the default namespace not apply to attributes?> From: noah_mendelsohn@u...=
bm.com> Date: Thu, 16 Aug 2007 14:26:58 -0400> > Speaking for myself, and n=
ot formally for the Schemas WG:> > the decision in Schemas to treat element=
s and attributes asymmetrically > reflects a related asymmetry in namespace=
s itself.  You'll note that per > XML Namespaces [1], default namespace bin=
dings to not apply to attributes. >  You can see this because per the names=
paces recommendation, the following > example does NOT have a duplicate att=
ibute (it's actually not important > that I've used two elements here, it's=
 just easier to separate the > namespace bindings from the attributes:> > >=
         <!-- prefix p and the default are bound to the same namespace URI =
> -_>>         <outer xmlns="http://example.org/ns" > xmlns:p="http://e=
xample.org/ns">>           <-- no duplicate attribute error in the followin=
g -->>           <inner a="1" p:a="2"/>>           <-- the following ha=
s the same element tag as the one above -->>           <p:inner />>        =
 </outer>> > Reading between the lines, the Namespaces recommendation takes=
 the view > that attributes tend to be scoped to the elements on which they=
 appear. > Also, it's quite common in colloquial XML usage, to find unquali=
fied > attributes on qualified elements.  Finally, while the connection is =
> indirect, DTDs do treat attributes as local to the element;  you can tell=
 > this because you can declare different default values for attribute "A" =
on > element "E1" vs. element "A" on "E2".  For all of these reasons, Schem=
as > defaults to a model in which attributes are unqualified, even if a > t=
argetNamespace is declared for a schema document.> > Noah> > [1] http://www=
.w3.org/TR/REC-xml-names/#uniqAttrs> > ------------------------------------=
--> Noah Mendelsohn > IBM Corporation> One Rogers Street> Cambridge, MA 021=
42> 1-617-693-4036> --------------------------------------> > > > > > > > >=
 Nanda Kol <nandakol@h...>> Sent by: xmlschema-dev-request@w...> 0=
8/16/2007 11:32 AM>  >         To:     <xmlschema-dev@w...>>         cc: =
    (bcc: Noah Mendelsohn/Cambridge/IBM)>         Subject:        Why does =
the default namespace not apply to > attributes?> > > All,>  > The followin=
g question is about the rationale for the difference in > approach between =
elements and attributes with regard to namespaces.>  > In order to promote =
reuse of XML artifacts within our organization, a set > of recommendations =
has been specified for XML Schema documents design. One > of the recommenda=
tions is that every XML Schema document should have a > target namespace. H=
owever, after some experiments and investigation we > learnt that this name=
space does not apply to attributes, which means that > the use of a target =
namespace results in attributes and elements being in > different conceptua=
l spaces, which seems counter-intuitive. >  > We have been wondering what c=
ould be the rationale behind this, but > couldn=92t find the answer. Hopefu=
lly, you can provide it or you know where > to search for it.>  > Moreover,=
 if you can provide us any directions on the best approach  (i.e. > set att=
ributeFormDefault to =93qualified=94, use global attribute > declarations, =
or else) with respect to reusability, this would be more > than welcome.>  =
> Thanks in advance,> Nanda> > Play free games, earn tickets, get cool priz=
es! Join Live Search Club.   > Join Live Search Club!> 
_________________________________________________________________
Play free games, earn tickets, get cool prizes! Join Live Search Club.=A0
http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink=