Re: [xsl] Namespace conflicts processing Word documents

["G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>]

At 2008-10-06 14:15 +0100, Peter Flynn wrote:
> [This doesn't appear to have been raised here or elsewhere; a search 
> for  combinations of ooxml, wordml, namespace returns zero hits. If 
> it has been answered online somewhere, I'd be grateful for a pointer.]
>
> WordML and OOXML files (Word saved-as-XML from vv2003-2008) contain 
> some different namespace declarations for the same prefix 
> (specifically w: but a few others).

Prefixes are cheap and ambiguous ... namespace-aware processing is 
based on the URI a prefix points to, not the prefix itself.  A WordML 
document using "w:" as a prefix is independent of an OOXML document 
using "w:" as a prefix.

> On the surface, this appears to mean that an XSLT file written to 
> process WordML files' w:* elements cannot be used to process OOXML 
> files' w:* elements -- two parallel versions are needed, one with 
> the WordML w: namespace and one with the OOXML w: namespace.

But XSLT only worries about the namespace URI and prefixes used in 
XSLT are independent of prefixes used in XML source documents.

Also, prefixes used in *different* XSLT fragments (even when imported 
or included) are independent of the prefixes used in the importing 
and including stylesheets.

This is because all of the documents described above are standalone 
XML documents so each document can have an independent set of prefixes.

> As the only document body elements in either case that I will need 
> to handle are identified by named styles, I would prefer to be able 
> to reuse the bulk of the templates by inclusion or importation. The 
> documents come from mixed sources, and I'd prefer not to have to ask 
> the authors to update their version of Word :-)

Not sure what you are saying there.  You can use "harry:" and 
"sally:" in your XSLT stylesheet and provided you have used the 
correct namespace URI strings, "harry:p" is a "p" in the WordML 
namespace and "sally:p" is a "p" in the OOXML namespace.

> I tested this by creating two "driver" XSLT files, one implementing 
> the WordML namespace declarations and one the OOXML ones; with both 
> files having a single xsl:import or xsl:include (tested both ways) 
> calling my file of templates which itself declared no namespaces except XSL.
>
> Both Saxon and xalan throw an error, saying that the namespace w: 
> was undeclared in all cases.

Understandably!  Prefixes have scope within an XSLT XML 
document.  The XSLT processor looks at the XML namespaces in scope to 
assign the qualified names to XPath addresses used in an XSLT 
document (except now in 2.0 there is the new xpath-default-namespace).

> This makes it appear that namespaces cannot be inherited from an 
> outer XSLT file to an included or imported one;

Absolutely they cannot ... XML documents are independent of each 
other ... so are XSLT documents.

> in effect that the omission of namespace declarations on the 
> included/imported xsl:stylesheet element nullifies all outer 
> namespace declarations.
>
> Is this correct, or have I missed something?

It is correct.

What I think you are missing is that an XSLT stylesheet has no 
obligation to use the same prefix as another XSLT stylesheet or any 
XML document being used as a source file.

An XSLT stylesheet using the "wanda:" prefix for "urn:x-Peter" will 
correctly address XSLT constructs in an imported or included 
stylesheet that uses "fish:" as the prefix for "urn:x-Peter".

I hope this helps.

. . . . . . . . . . Ken

--
Upcoming XSLT/XSL-FO hands-on courses:      Wellington, NZ 2009-01
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video sample lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg
Video course overview:  http://www.youtube.com/watch?v=VTiodiij6gE
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal