[
Lists Home |
Date Index |
Thread Index
]
> If you want to think of it that way, it's fine, but I don't think
> applications should have to worry very hard about it.
I don't _want_ to think that way, but it seems your proposed
chaneg would force me to think of them that way.
If I have two elements <x:foo a=".."/> and <x:bar a=".."/>
then currently I can think of the a attributes being unnamespaced
and so not having any global definition, and so in particular having
definition derived from their elements.
If on the other hand things are changed so that each of these is
considered to be the a attribute in the namespace bound to x:
then don't doesn't that lead to the conclusion that these attributes
having the same globally unique namespaced name ought to be the same
attribute and taht furthermore, being a an attribute with a gloably
unique name, it ought to be a global attribute that can be used
anywhere?
> (I've used html:href myself in IE, where there's no other way to make a
> link in XML, but I think it's pretty plainly a horrible kluge.)
But currently that is just wrong (Html doesn't have a globally defined
href attribute). My objection to your suggestion is that it would make
this right as the href attribute on img would become an href in teh html
namespace.
> but I'm not sure what to think
> of its rejection of xsl:version on XSLT elements. I'd guess overall
> that it's a mistake,
It's needed given the current namespace spec, otherwise you'd have
to say what to do if you had version="1" xsl:version="2" and as we all
agree someone (either xml namespaces or xslt spec) had better say don't
do that.
David
_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
|
