[
Lists Home |
Date Index |
Thread Index
]
>
> > On what basis do you make this inference?
> the purpose of putting an attribute (or element) into a namespace is to
> ne able to refer to that attribute or element name unambiguously from
> other contexts. That's the _only_ thing that xml namespaces do: give
> a method of allocating globally unique names.
>
> so if you use an attribute in a namespace then the reason for doing that
> (should) be so you can use that attribute in different contexts.
> this is why xlink attruibutes (and xml:lang etc) are namespaced.
Another unjustified logical leap, IMO. This is the reason for making
specifications of attributes that can be used in other vocabularies. I don't
see that it follows that it is the only justification for "putting attributes
in a namespace".
If your reasoning were to be followed, then the nasty SOAP and XSD pattern of
non-namespaced child elements would make sense, and I can't accept that.
Let's look at an XSLT example.
<xsl:choose>
<xsl:when...>
<xsl:otherwise...>
</xsl:choose>
xsl:when and xsl:otherwise cannot appear outside xsl:choose, so by your
reasoning, this should be better written
<xsl:choose>
<when...>
<otherwise...>
</xsl:choose>
Since, as you say, the *only* reasin to give something a namespace is to allow
it to be inserted willy-nilly into other vocabularies.
Luckily, this premise of yours is not creditable. Constructs can be placed in
the same namespace as other constructs in order to retain a close association
with those other constructs, whether or not those contructs are meant to be
inserted directly into other vocabularies. Namespaces group vocabularies, and
not everything in a vobabulary has to be "global".
> > This specification makes no assertions as to the proper usage of such
> > attributes. The combination of the namespace name and the attribute name
> > uniquely identifies the global attribute.
>
> in other words the phrase "global attribute" and "attribute in a
> namespace" currently mean the same thing. which is why several people
> have commented that unless you furher qualify something, a change that
> puts unprefixed attributes into the namespace of their elements
> will make them global attributes.
>
> Thus Simon's and your assertion that putting these attributes into a
> namespace does not make them global is wrong.
> It would of course be possible to change more of the namespace spec and
> change the definition of a global attribute. If that was done carefully
> the objections might go away but without seeing all the proposed
> changes, who can tell.
As I've already said, the definition of a global attribute is not important.
If you are saying that you want to see Simon and me write a complete anf
formal revision of the namespace spec before making odd logical leaps about
what we're trying to say, then I'm afraid we just won't be able to have a
fruitful discussion.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Track chair, XML/Web Services One Boston: http://www.xmlconference.com/
Basic XML and RDF techniques for knowledge management, Part 7 -
http://www-106.ibm.com/developerworks/xml/library/x-think12.html
Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/libra
ry/x-jclark.html
Python and XML development using 4Suite, Part 3: 4RDF -
http://www-105.ibm.com/developerworks/education.nsf/xml-onlinecourse-bytitle/8A
1EA5A2CF4621C386256BBB006F4CEC
|
