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(_at_)CraneSoftwrights(_dot_)com
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
--~------------------------------------------------------------------
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>
--~--