[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Re: Unwanted namespace prefix _0


Subject: Re: [xsl] Re: Unwanted namespace prefix _0
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxx>
Date: Mon, 23 Dec 2013 13:37:59 -0500

Martin,

As the other Martin says, I think we need more details. I think this
should be fixable, but it's subtle.

In particular, it would be helpful to know whether the 'eg:egXML'
element (I use a namespace prefix for clarity) is in your result
because it is being copied from the source data, or because it is
inserted by the stylesheet.

I think the reason for the unwanted prefix is that Saxon sees you need
the namespace because it's being used deep in the tree, but it is
actually in scope for the entire result tree, which already has
unprefixed names in another namespace, so we need a prefix for this
one. (The namespace having been declared at the top of the stylesheet,
every element in the stylesheet inherits it.) Given this complication,
Saxon doesn't have warrant or means to determine what's most
parsimonious to your and me eye.

The way to prevent this is by removing the declaration for the 'eg'
namespace from the top of the stylesheet, and only keeping it where
you need it -- which may not be anywhere if the stylesheet doesn't
need it (the namespace) for its own purposes.

This is the first thing I'd try -- have no declaration in your XSLT
for namespace "http://www.tei-c.org/ns/Examples". If you need to match
with it, do something like:

<xsl:template match="egXML"
   xpath-default-namespace="http://www.tei-c.org/ns/Examples">
  <xsl:copy-of select="."/>
<xsl:template>

If you must have the namespace declaration because you need to
generate results in it (not just copy into the results from the input)
then try keeping the declaration local to the element (or elements)
where it is needed. (Of course this is contrary to the 'namespace
hygiene' rule we ordinarily follow.)

<xsl:template name="newExample">
  <!-- since the namespace is declared here, it isn't in scope
elsewhere in the stylesheet -->
  <egXML xmlns="http://www.tei-c.org/ns/Examples">
    <ab>New example here</ab>
  </egXML>
</xsl:template>

Or, a bigger stick (which I would rather avoid):

<xsl:template name="newExample">
  <xsl:element name="egXML" namespace="http://www.tei-c.org/ns/Examples">
    <xsl:element name="ab"
namespace="http://www.tei-c.org/ns/Examples">New example
here</xsl:element>
  </xsl:element>
</xsl:template>

I hope this helps.

Cheers, Wendell
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^


On Mon, Dec 23, 2013 at 12:49 PM, Martin Holmes <mholmes@xxxxxxx> wrote:
> Another oddity is this: even if I define a namespace prefix for the Examples
> namespace:
>
>  xmlns:eg="http://www.tei-c.org/ns/Examples"
>
> in the stylesheet root element, Saxon still uses the _0 prefix in the
> output.
>
> It's easy to cleanup with a regex search-and-replace, but it's really
> annoying. There must be some way around it, otherwise people would be asking
> this question all the time, surely? I assumed I'd just forgotten something
> obvious or screwed something up.
>
> Cheers,
> Martin
>
>
> On 13-12-23 08:29 AM, G. Ken Holman wrote:
>>
>> At 2013-12-23 08:16 -0800, Martin Holmes wrote:
>>>
>>> Hi all,
>>>
>>> I'm doing an identity transform with Saxon 9.5.1.2 (HE, PE and EE all
>>> do the same) on a TEI file with embedded examples in the Examples
>>> namespace:
>>>
>>> <TEI xmlns="http://www.tei-c.org/ns/1.0" version="5.0">
>>> [...]
>>> <div>
>>> <egXML xmlns="http://www.tei-c.org/ns/Examples" valid="true">
>>>   For more information, consult the
>>>   <ref target="mol:linking#linking_graphics"> guide to
>>>   linking graphic content</ref>.</egXML>
>>> </div>
>>> [...]
>>> </TEI>
>>>
>>> In the output, Saxon generates unwanted namespace prefixes, like this:
>>>
>>> <_0:egXML xmlns:_0="http://www.tei-c.org/ns/Examples" valid="true">
>>>   For more information, consult the
>>>   <_0:ref target="mol:linking#linking_graphics"> guide to
>>>   linking graphic content</_0:ref>.</_0:egXML>
>>>
>>> This is even though I have exclude-result-prefixes="#all", and it
>>> happens whether or not I define a prefix in the root stylesheet
>>> element for the Examples namespace.
>>>
>>> What am I missing?
>>
>>
>> That exclude-result-prefixes= has no impact on namespaces in input
>> trees, it only prunes the stylesheet tree literal result elements of
>> unwanted namespaces (though the actual prohibition typically happens
>> during serialization, conceptually it is as if the namespaces were
>> pruned from the stylesheet tree).
>>
>>> How would I get output that looks exactly like the input?
>>
>>
>> Have you considered reconstituting each element explicitly with no prefix?
>>
>>    <xsl:element name="{name()}" namespace="{namespace-uri()}">
>>
>> Though I could imagine it has no effect since it will build an exact
>> replica of the result tree as a copy.  If you know that what you want is
>> in the default namespace you could try:
>>
>>    <xsl:element name="{local-name()}" namespace="{namespace-uri()}">
>>
>> But, again, it will likely build the exact result tree.
>>
>> I'm making these suggestions just in case Saxon looks to the result tree
>> creation for a hint regarding serialization.
>>
>> The specification doesn't provide such control over serialization, so
>> Saxon is within its rights to do what it wants.  You could look in the
>> Saxon documentation for a private extension that would govern the rules.
>>
>> I hope this helps.
>>
>> Happy holidays to list readers!
>>
>> . . . . . . . . Ken
>>
>> --
>> Public XSLT, XSL-FO, UBL & code list classes: Melbourne, AU May 2014 |
>> Contact us for world-wide XML consulting and instructor-led training |
>> Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
>> Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
>> G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
>> Google+ profile: https://plus.google.com/116832879756988317389/about |
>> Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |


Current Thread
Keywords