XSL: Adding namespace prefix to elements read from external file

[johanneskrueger]

Hello,

I'm currently using <xsl:copy-of select="document(...)/svg:svg"/> to
embed an SVG file into an XHTML file. I already defined the SVG
namespace and assigned svg as its prefix in my XSLT 1.0 sheet.

What commands instead of copy-of could I use in order to get the
prefix with every element from the external file, e.g. <svg:svg>,
<svg:line> etc. instead of just <svg> and <line>, as it is noted in
the external file?
I tried to create new elements and assign everything, but it didn't
work out so far.


Thank you for any helpful suggestion!

Regards,
Johannes

 

[Martin Honnen]

I'm currently using <xsl:copy-of select="document(...)/svg:svg"/> to
embed an SVG file into an XHTML file. I already defined the SVG
namespace and assigned svg as its prefix in my XSLT 1.0 sheet.

What commands instead of copy-of could I use in order to get the
prefix with every element from the external file, e.g. <svg:svg>,
<svg:line> etc. instead of just <svg> and <line>, as it is noted in
the external file?
I tried to create new elements and assign everything, but it didn't
work out so far.

Does the external SVG document define the SVG namespace properly (e.g.
as its default namespace
<svg xmlns="http://www.w3.org/2000/svg">
or with some prefix e.g.
<svg:svg xmlns:svg="http://www.w3.org/2000/svg">
)? Then xsl:copy-of should suffice to create elements in the SVG
namespace in the result tree. The prefix finally used for serialization
should not matter.
Or why are you interested in the prefix?

 

[Joe Kesselman]

What commands instead of copy-of could I use in order to get the

prefix with every element from the external file, e.g. <svg:svg>,
<svg:line> etc. instead of just <svg> and <line>, as it is noted in
the external file?

Assuming that everything is working properly (which it may not be, but
you haven't shown us an example)... What may be happening is that your
system's serializer has chosen to make the SVG namespace the default
namespace; once that's been done, the prefix does not have to appear on
every element (but all contained elements which are *NOT* in that
namespace must either have a prefix or a new default namespace
declaration to break that association).

The above also assumes you're going through a standard serializer. If
you're taking the XSLT processor's output directly as SAX or DOM, the
prefixes may not be present, since they're considered "syntactic sugar";
you should be operating entirely off the localname and namespace URI, or
explicitly running the output document through a normalization stage if
you need the prefixes (which, as I said, is normally done in the
serializer if you're outputting XML markup).

If you want more specific advice, you'll have to be more specific about
what you're doing and what you're seeing. A small (ten-line or so)
example can be useful as a way of explaining that.

 

[johanneskrueger]

Hello,

thanks for your replies. To illustrate what is going on, I made some
excerpts from my XSLT stylesheet and pasted them at the end.
The SVG files to be inserted start with <svg xmlns:"http://www.w3.org/
2000/svg" ... >, i.e. they have the correct namespace URI but no
prefix assigned.

As I need the output code for some kind of demonstration, I'd rather
include the prefixes with the SVG section.

Regarding your answer, Joe, I didn't entirely get what you said in the
2nd paragraph. I'm just feeding my files into Instant Saxon and have a
look at its output.


Regards,
Johannes


XSLT file header and root:

<?xml version="1.0" encoding="utf-8"?>
<xsl:transform xmlns="http://www.w3.org/1999/xhtml" xmlns:xsl="http://
www.w3.org/1999/XSL/Transform"
xmlns:math="http://www.w3.org/1998/Math/MathML" xmlns:svg="http://
www.w3.org/2000/svg" version="1.0">

When a reference to a SVG file is found, a template is called to
process it:

<xsl:call-template name="getFigure">
<xsl:with-param name="svgfile"><xsl:value-of select="@src"/></
xsl:with-param>
</xsl:call-template>

<xsl:template name="getFigure">
<xslaram name="svgfile"/>
<xsl:copy-of select="document($svgfile)/svg:svg"/>
</xsl:template>

 

[Joe Kesselman]

The SVG files to be inserted start with <svg xmlns:"http://www.w3.org/
2000/svg" ... >, i.e. they have the correct namespace URI but no
prefix assigned.

Which is fine; you're using the default namespace.

As I need the output code for some kind of demonstration, I'd rather
include the prefixes with the SVG section.

Unfortunately, while there's an official mechanism in XSLT 1.0 for
hinting that a prefix may not be needed, there isn't a clear one for
hinting that you _do_ want it used preferentially.

I guess you could try forcing an explicit declaration of the svg: prefix
into your output document, and see if that's enough of a hint for your
processor to realize that you want it to use this prefix rather than a
default binding... something like:

<xsl:template name="getFigure">
<xslaram name="svgfile"/>

<svg:svg xmlns:svg="http://www.w3.org/2000/svg">

</xsl:template>

If you really need a reliable portable solution... ugh. Best I can think
of is to recreate copy-of via recursion, and set up a template which
matches elements in the svg namespace and explicitly reconstructs them
using xsl:element with prefix="svg"... And even that may not be
guaranteed, depending on how the document is processed after it leaves
the XSLT engine.

 

[johanneskrueger]

I guess you could try forcing an explicit declaration of the svg: prefix
into your output document, and see if that's enough of a hint for your
processor to realize that you want it to use this prefix rather than a
default binding... something like:


<svg:svg xmlns:svg="http://www.w3.org/2000/svg">
<xsl:copy-of select="document($svgfile)/svg:svg/(@*|node())"/>

That didn't work I'm afraid. After all, the processor is obviously
aware of the namespace prefix (at least for the elements within the
stylesheet). It was mandatory to write document($svgfile)/svg:svg,
whereas document($svgfile)/svg wouldn't work. I'll give the creation
of new elements another try and will drop a note when it works out.


Regards,
Johannes