[
Lists Home |
Date Index |
Thread Index
]
>
> > 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?
If so, then of course. The whole point is that I'm advocating *changing* from
XML 1.0. I am advocating that an unprefixed attribute should be in the
namespace of its parent, or at least that APIs should provide the ability for
this view to be imposed.
> > The distinction between local and global attributes is only a way to
> > get at the important information i.e. what is the namespace of the
> > attr.
>
> No you don't need to have a local/global distinction to get at the name
> of the attribute. That is explicit in the syntax. The distinction is
> that globally defined attributes (essentially a namespace invention as
> far as XML is concerned) are defined, and can be referred to independly
> of any element.
I think you and I are speaking entirely different languages. The local/global
distinction ("global" as defined in XMLNS and "local" as logically
extrapolated in this thread) *is precisely* what is "implicit in the syntax".
> Assuming some conventional namespace bindings
> html:img
> is a way of refering to the the img element of html.
> There is no such qname that uniquely refers to the href attribute
> of that element. This is a good thing. Even within HTML attributes
> with the same name are not always directly compararble and many of them
> wouldn't make sense if used on elements from other namespaces.
I don't understand what you wrote here.
> with the proposed change the href attribute of html:img would be
> considered to be in the xhtml namespace and equivalent to an attribute
> html:href. that means that the html namespace now must have such an
> attribute that can be globally referred to as
> html:href
Why? From where do you make that amazing logical leap? Is it something in
the para above that I was unable to understand?
> so suddenly you have a global attribute which you can put on other
> elements
> <foobar html:href=...
I thoroughly lost your logic. In my proposal, a global attribute is one that
is not in the namespace of its element. I said nothing whatsoever about
adding rules that allow attributes from one namespace to be inserted into
another. That is outside the boinds of XMLNS.
If I understand you rightly, you claim that the fact that in
<a:spam a:eggs/>
the attribute would be in the same namespace as
<a:spam eggs/>
That this suddenly means that in all cases it becomes OK to write
<b:monty a:eggs/>
On what basis do you make this inference? I certainly do not agree. By the
same token, what under XMLNS as it is now prevents you from writing
<b:monty eggs/>
?
The answer is *nothing*. This allowance or prohibition has nothing to do with
namespaces. It has to do with the schematics of the vocabulary itself.
Entirely independent matter.
--
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
|
