[XML-SIG] namespace headache

Uche Ogbuji uogbuji@fourthought.com
Tue, 02 May 2000 12:41:40 -0600


> I'm pretty sure an unprefixed attribute will default to the same namespace
> URI as its host element, so in the snippet:

No!  A million times "no"!  There is _no_ defaulting for attributes.  None 
whatsoever.

This is a major XML FAQ and I refer everyone to James Clark's excellent note, 
which /F already mentioned.

http://www.jclark.com/xml/xmlns.htm

> <ns:body xmlns:ns='namespace:'>
>     <ns:member attribute='value'>
>     </ns:member>
> </ns:body>
> 
> 'attribute' would have the namespace URI 'namespace:', as its host element,
> whereas in:
> 
> <body>
>     <member attribute='value'>
>     </member>
> </body>
> 
> it would have no namespace URI. I think I read about this somewhere in the
> namespace specification at W3C. This also explains why XSL-specific
> attributes in XSLT elements needn't be prefixed (they will conveniently
> default to the same namespaces as their host elements, i.e. the XSLT
> namespace). The same goes for XHTML, I guess. I think xmllib has it right. I
> have no explanation for James Clark's note however. The alternative of
> forcing the XML author to explicitly prefix every attribute in elements that
> belong to a certain namespace just to declare that they belong to the same
> namespace seems pretty inconvenient.

I'll grant that you pretty much explained the reason for much of the 
confusion.  However, the fact that XSLT uses unprefixed attributes has no 
bearing on their namespace status.  XSLT does this as a convenience: after 
all, XSLT processors are element-oriented (if that means anything), and will 
recognize the standard attributes of an XSL instruction without help from 
namespaces.  Since there is no attr namespace defaulting, my guess is that 
unprefixed instruction attributes is a way to make XSLT a tad less verbose, 
but no more than that.

-- 
Uche Ogbuji                               Senior Software Engineer
uche.ogbuji@fourthought.com               +01 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-9036, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python