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 ]
  • To: "Simon St.Laurent" <simonstl@simonstl.com>
  • Subject: Re: [xml-dev] Re: URIs, concrete (was Re: [xml-dev] Un-ask the question)
  • From: Tim Bray <tbray@textuality.com>
  • Date: Thu, 01 Aug 2002 07:48:49 -0700
  • Cc: XML DEV <xml-dev@lists.xml.org>
  • References: <r01050300-1015-627F11D4A4D211D693BB0003937A08C2@[192.168.124.21]>
  • User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1b) Gecko/20020722

Simon St.Laurent wrote:

> Yes, and you've completely missed my point yet again.  I'm not arguing
> that prefixed attributes should be in the namespace of the element
> containing them.  I'm arguing that _unprefixed_ attributes should be
> treated as if they had the same namespace as the element containing
> them.

I mostly agree.  You've argued that doing the following

<x:y xmlns:x="http://example.com/"; x:a="1" a="2" />

while legal per the ns rec, is idiotic and shouldn't be done.  Agreed. 
You've further argued that it was a design error that the ns rec allws 
this.  Agreed.

Where we may disagree is, if you're making an API, you'd better not 
report the final attribute above (to use JJC's notation) as 
{http://example.com}a, whether or not the first attribute is there or 
not.  For better or worse, at the API level, the final attribute there 
has a local part of "a" and no namespace name, but is attached to an 
element with a namespace name. -Tim





 

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

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