Noah, thank you for your answer. > <!-- prefix p and the default are bound =
to the same namespace URI > -_>> <outer xmlns="http://example.org/ns" > x=
mlns:p="http://example.org/ns">> <-- no duplicate attribute error in the =
following -->> <inner a="1" p:a="2"/>> <-- the following has the same e=
lement tag as the one above -->> <p:inner />> </outer>I see that your examp=
le presents a valid piece of XML, but I believe there are other =96 more re=
adable - ways to have two attributes with the same name in one element. I b=
elieve the XML in your example leads to confusion, as to which namespace th=
e attributes belong, especially because elements don=92t need a prefix to i=
ndicate they belong to the target namespace, whereas attributes do. At firs=
t sight, one would think that both =93a=94 and =93p:a=94 belong to the same=
 namespace (the same that is also associated with the =93inner=94 and =93ou=
ter=94 element), whereas actually the first occurrence of =93a=94 does not =
belong to a namespace at all. Wouldn=92t it be more intuitive and improve r=
eadability to have both of the attributes in a different namespace, instead=
 of one attribute being in no namespace? Let=92s say, if the default namesp=
ace would apply to attributes, the following two examples would represent t=
he same thing, i.e. the =93p:a=94 would be equal to the =93a=94.Example 1--=
-------<!-- prefix p and the default are bound to the same namespace URI --=
><outer xmlns="http://example.org/ns"        xmlns:p=http://example.org=
/ns       xmlns:q=http://example2.org/ns>  <-- no duplicate attribute err=
or in the following -->  <inner p:a="1" q:a="2">  <-- the following has=
 the same element tag as the one above -->  <p:inner /></outer>Example 2---=
------<!-- prefix p and the default are bound to the same namespace URI -->=
<outer xmlns="http://example.org/ns"        xmlns:p=http://example.org/=
ns       xmlns:q=http://example2.org/ns>  <-- no duplicate attribute erro=
r in the following -->  <inner a="1" q:a="2">  </inner></outer>Neverthe=
less, per [1] attribute =93a=94 in Example 2 does not belong to same namesp=
ace as =93p:a=94 in Example 1, thus the examples do not represent the same =
thing. > Reading between the lines, the Namespaces recommendation takes the=
 view > that attributes tend to be scoped to the elements on which they app=
ear. I saw this statement as well, but to me it does not provide sufficient=
 rationale for not applying the default namespace to attributes.> Also, it'=
s quite common in colloquial XML usage, to find unqualified > attributes on=
 qualified elements.Probably, this is because normally one doesn=92t really=
 notice the difference and as long as a document validates, many people don=
=92t think about it. It only becomes clear when you start referencing them =
(e.g using =93key=94 and =93keyref=94) and see that the document does not v=
alidate if you use a prefix both for the element and the attribute (because=
 the attribute does not belong to the same namespace).XML Schema snippet---=
---------------<xs:element name==94inner=94 type==94innerType=94>  ....=
  <xs:attribute name==94a=94 type==94aType=94/></xs:element>XML instanc=
e snippet (INVALID)------------------------------<xsd:keyref refer="key" =
name="keyRef">  <xsd:selector xpath=".//p:inner"/>  <xsd:field xpath==
"@p:a"/></xsd:keyref>In summary I would say that your answer has not yet co=
nvinced me and I look forward to continuation of the discussion. Best regar=
ds,Nanda[1] http://www.w3.org/TR/REC-xml-names/#uniqAttrs> To: nandakol@hot=
mail.com> CC: xmlschema-dev@w...> Subject: Re: Why does the default names=
pace not apply to attributes?> From: noah_mendelsohn@u...> Date: Thu,=
 16 Aug 2007 14:26:58 -0400> > Speaking for myself, and not formally for th=
e Schemas WG:> > the decision in Schemas to treat elements and attributes a=
symmetrically > reflects a related asymmetry in namespaces itself.  You'll =
note that per > XML Namespaces [1], default namespace bindings to not apply=
 to attributes. >  You can see this because per the namespaces recommendati=
on, the following > example does NOT have a duplicate attibute (it's actual=
ly not important > that I've used two elements here, it's just easier to se=
parate the > namespace bindings from the attributes:> > >         <!-- pref=
ix p and the default are bound to the same namespace URI > -_>>         <ou=
ter xmlns="http://example.org/ns" > xmlns:p="http://example.org/ns">>  =
         <-- no duplicate attribute error in the following -->>           <=
inner a="1" p:a="2"/>>           <-- the following has the same element=
 tag as the one above -->>           <p:inner />>         </outer>> > Readi=
ng between the lines, the Namespaces recommendation takes the view > that a=
ttributes tend to be scoped to the elements on which they appear. > Also, i=
t's quite common in colloquial XML usage, to find unqualified > attributes =
on qualified elements.  Finally, while the connection is > indirect, DTDs d=
o treat attributes as local to the element;  you can tell > this because yo=
u can declare different default values for attribute "A" on > element "E1" =
vs. element "A" on "E2".  For all of these reasons, Schemas > defaults to a=
 model in which attributes are unqualified, even if a > targetNamespace is =
declared for a schema document.> > Noah> > [1] http://www.w3.org/TR/REC-xml=
-names/#uniqAttrs> > --------------------------------------> Noah Mendelsoh=
n > IBM Corporation> One Rogers Street> Cambridge, MA 02142> 1-617-693-4036=
> --------------------------------------> > > > > > > > > Nanda Kol <nandak=
ol@h...>> Sent by: xmlschema-dev-request@w...> 08/16/2007 11:32 AM=
>  >         To:     <xmlschema-dev@w...>>         cc:     (bcc: Noah Men=
delsohn/Cambridge/IBM)>         Subject:        Why does the default namesp=
ace not apply to > attributes?> > > All,>  > The following question is abou=
t the rationale for the difference in > approach between elements and attri=
butes with regard to namespaces.>  > In order to promote reuse of XML artif=
acts within our organization, a set > of recommendations has been specified=
 for XML Schema documents design. One > of the recommendations is that ever=
y XML Schema document should have a > target namespace. However, after some=
 experiments and investigation we > learnt that this namespace does not app=
ly to attributes, which means that > the use of a target namespace results =
in attributes and elements being in > different conceptual spaces, which se=
ems counter-intuitive. >  > We have been wondering what could be the ration=
ale behind this, but > couldn=92t find the answer. Hopefully, you can provi=
de it or you know where > to search for it.>  > Moreover, if you can provid=
e us any directions on the best approach  (i.e. > set attributeFormDefault =
to =93qualified=94, use global attribute > declarations, or else) with resp=
ect to reusability, this would be more > than welcome.>  > Thanks in advanc=
e,> Nanda> > Play free games, earn tickets, get cool prizes! Join Live Sear=
ch Club.   > Join Live Search Club!> 
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/=