Re: [xsl] I need to make sure that all namespace declarations get output to a particular element, not the document element

Subject: Re: [xsl] I need to make sure that all namespace declarations get output to a particular element, not the document element
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Thu, 22 Mar 2007 11:43:17 -0400
At 09:14 AM 3/22/2007, Ken wrote:
At 2007-03-22 13:51 +0100, bryan rasmussen wrote:
I have a situation where the processor is obviously optimising
namespace creation and placing them all over the place, unfortunately
I need to place them exactly on a particular element.

I've not heard of a processor moving a required namespace declaration "up" the result tree. Once an element in the result tree is constructed, the adding of children nodes to the element wouldn't typically change the completed parent element.

Exactly. To "promote" the declaration in this way would be actually to alter the model, albeit in a subtle way, of the result.

When I've had to do the opposite -- get all namespaces declared at the top (this has generally been only for cosmetic reasons, but cosmetic reasons can be important to certain classes of users) -- I've done it by explicitly copying namespace nodes found further down to the top of the tree. Typically this is done in a completely separate transform in a pipeline (and typically the last one in the pipeline), since strictly speaking it relies on features in the serializer (regarding assignment of prefixes to namespaces), which is outside the proper purview of XSLT and pushes its boundaries. I've done this to address the requirement even though I don't like it: namespace nodes give me headaches, and as others have posted, it should be unnecessary. So it seems like a good procedure to quarantine.

Namespaces are pesky and problematic because they're "meta". They're not markup, they're markup of the markup. I can see why their designers liked them, and they do handle certain classes of problems well. But they're also exactly the kind of trickiness that makes for problems down the line: too smart. Their subtleties (URIs pressed into service as globally unique identifiers?), and the way they refuse to stay on either side of the model vs representation divide (which is the real thing: the tree or the tag?), create confusion and misleading impressions, and thus what Mike just called "appalling design flaws". Which lead to more problems.


====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================

Current Thread