Re: Re: URIs, concrete (was Re: Un-ask the question)
I may as well take this on directly, especially as Tim Bray has already acknowledged that leaving unprefixed attributes in no namespace was "a design error". I take John's interpretation of the specification to be accurate, but its implications to be decidedly wrong. The namespaces specification made a simple but horrid mistake in failing to recognize the close relationship between an attribute and its containing element. That there is a difference between: <x:foo x:bar="bogus"/> and: <x:foo bar="bogus"/> seems like yet another consequence of a disastrous specification. As monasticxml.org is a reflection of my complete impatience with broken specifications, suggesting that practice treat this bogus distinction without much respect seems entirely appropriate. It's not like we need ANOTHER problem with this specification to shout from the rooftops... It's time to start fixing stuff instead of just letting bad decisions perpetuate themselves. In practice, I really doubt that this will break ANY applications. John Cowan writes: > W. E. Perry scripsit: > > > But what does it mean, really, for an attribute to be 'in a > namespace', > > separate from that attribute appearing (or being declared in an > ATTLIST as) > > within the scope of a particular element? > > It means that, under the Namespaces Rec, the following pair is > equivalent: > > <foo xmlns="urn:baz:32" bar="47"/> > <baz:foo xmlns:baz="urn:baz:32" bar="47"/> > > but the following pair is not: > > <foo xmlns="urn:baz;32" bar="47"/> > <baz:foo xmlns:baz="urn:baz:32" baz:bar="47"/> -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format