[xsl] XSLT 2.0 HTML output of namespace nodes

[Mike Brown <mike at skew dot org>]

This has been a pet topic of mine for a long time now...

I was under the impression that it was an oversight in XSLT 1.0 that the HTML 
output method, by its requirement to not differ from the XML output method
except in certain specified manners, required the serialization of namespace 
nodes as xmlns attributes.

However, upon reviewing the HTML output section of the XSLT 2.0 WD, I see that
this behavior has been prescribed even more formally than before:

"The html output method should not output an element differently from the xml 
output method unless the expanded-name of the element has a null namespace 
URI; an element whose expanded-name has a non-null namespace URI should be 
output as XML."

What is the rationale behind this?

I disagree with it, whatever it is :)

My argument is this:

1. Namespace nodes are an artifact of the XPath data model, which is based on 
   a namespace-aware interpretation of an XML document. HTML 4.x does not have
   any concept of namespaces, so namespace nodes in the result tree should be
   completely ignorable. Think of it this way: I could invent a result tree
   serialization scheme that produces a PNG of a chessboard, using information
   in only some subset of the result tree -- comment nodes, for example -- to
   determine the positioning of each player's pieces on the board. There is no
   requirement that I force some kind of serialization of the other nodes,
   because there is no requirement that I be able to reconstruct the result
   tree by reparsing my chessboard. Well, HTML is the same way. There is no
   mandate that an HTML document produced by the HTML output method be
   reparseable in a manner that would recreate the result tree from which it
   was derived.

2. xmlns attributes that are intended to convey namespace bindings have no 
   place in a document that purports to be HTML. There's nothing stopping an
   HTML document author from putting xmlns attributes in their documents,
   but as far as any standard HTML-parsing tools are concerned, these are 
   opaque attributes with no special meaning whatsoever. When xmlns attributes
   appear in an HTML document, it seems to be confusing, even irritating, to
   at least 50% of the users of XSLT, in my observation.

So if we ignore namespace nodes by default, questions remain:

1. My result tree contains 2 different elements or attributes with the same
local-name but in different namespaces. How do I represent them in HTML as
unique element types (or do I?)

2. Why not use exclude-result-prefixes? Doesn't that solve your problem?

No; see #3.

3. I want to produce an HTML element with a colon in its name, like "foo:bar". 
What serialization scheme needs to be applied to what nodes in the result tree 
in order to do this?

I think the answer to these two questions is a compromise: Use the namespace
nodes in the result tree to produce prefixed HTML element tags, just like the
XML output method does. But don't serialize the namespace nodes themselves. If
no prefixes are available, they should be automatically generated. It falls on
the stylesheet author to enforce the use of prefix bindings in the result tree
if they want to avoid automatic prefix generation.

4. I have a nonstandard HTML-parsing tool that does treat xmlns attributes as 
namespace bindings, so I need to be able to either map prefixed element names 
to namespace URIs, or put an xmlns="{nsURI}" on every element.

I think the answer to this one is that it is not the XSLT processor's concern 
if you want to use a nonstandard tool to read in your serialized output. The 
XSLT processor only needs to produce 'good' HTML. A compromise here might be
to make the output of xmlns attributes an option that is off by default.


My conclusion:

The HTML output method should not serialize namespace nodes by default. The
option to do so should be allowable, but I would prefer to see the activation
of this behavior be achieved by a processor-specific extension attribute on
the xsl:output element, much the same way the current prescription is to emit
the nodes by default and to turn off the behavior with a processor-specific
extension attribute.


So what am I missing here?

   - Mike
____________________________________________________________________________
  mike j. brown                   |  xml/xslt: http://skew.org/xml/
  denver/boulder, colorado, usa   |  personal: http://hyperreal.org/~mike/

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list