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.
Cheers,
Wendell
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
Mulberry Technologies, Inc. http://www.mulberrytech.com
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
======================================================================
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--