OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Re: URIs, concrete (was Re: [xml-dev] Un-ask the question)

[ Lists Home | Date Index | Thread Index ]

David Carlisle wrote:
> > I'm saying that applications and humans should ignore the
> > distinction.)
> 
> maybe it's just a wording thing.
> 
> but it sems to me that if I'm to treat the href attribute in <html:a
> href=... as being in the XHTML namespace then I am to think of it as
> being equivalent to <html:a html:href=... and that if I am to think
> of the html namespace as having an href attribute then I should
> expect to be able to use it on any element if I declare the html
> namespace (just as for xlink).

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'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.)

> > though I'm not sure I want to hold
> > up XLink or W3C XML Schema's xsi:stuff as a shining example.
> 
> well no, certainly not schema:-) but the general idea of namespaced
> attributes seems useful (if not so far well used). And I think your
> proposed change would impact on that (even though you explictly stated
> that it would not).
> 
> Any sensible application that has both namespaced and unnamespaced
> attributes will have application specific rules to avoid the
> rdf example that you state. For example xslt has both a version
> attribute (for use on xslt elements) and an xsl:version attribute
> for use on other elements) XSLT rules ensure that you can not use
> xsl:version on xslt elements.

I find the need for such application-specific rules to deal with such a
simple circumstance to be appalling.  If anything, you've just convinced
me that best practices are NOT enough to address this, and that the
namespaces specification itself should change.

In some ways XSLT is doing exactly what I propose (by treating its own
attributes as part of its own vocabulary) 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, but not an easily fixed one.  (I've never been
happy with the interactions between namespaces and XSLT, so maybe I
shouldn't be surprised.)

-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS