Re: [xslt] About bug #62565

[darrell dupas <ddupasedm netscape net>]

thanks, i am just taking my time getting into all of this and, hmm, it 
is very interesting, i like it and hope to use it,  i am also 
discovering the organization of gnome projects, i just hope i dont ask 
any dumb questions, should i have posted this message to the list?

i had the garbled output using exslt node sets, and inline tree 
fragments stored as variables in xslt, just a quick question if i could 
trouble you .. ...

tbroyer@ltgt.net wrote:

>Hi all,
>
>Bug #62565 is available at <http://bugzilla.gnome.org/show_bug.cgi?id=62565>
>
>This is *not* a bug but a misunderstanding of result tree fragments.
>The $inline_nodeset variable is a result tree fragment (not a node-set!)
>and XSLT defines a result tree fragment as follows:
>1. in 11.1 Result Tree Fragments:
>    A result tree fragment is treated equivalently to a node-set
>    that contains just a single root node
>2. in 11.2 Values of Variables and Parameters
>    The value is a result tree fragment equivalent to a node-set
>    containing just a single root node having as children the
>    sequence of nodes produced by instanciateing the template.
>
>So common:node-set($inline_nodeset) returns a node-set containing only a
>

where do i find out about the various namespaces, in this case comon: ?
you can tell me if it is easy to find

>
>single root node with three «node» children. To select these nodes, you
>have to use common:node-set($inline_nodeset)/node
>
>When you select common:node-set($inline_nodeset), you select a root node
>(to which the match="/" template should be applied, which is not the case
>in LibXSLT --as the root node is actually a «fake» element node-- and it is
>a bug, but not urgent to fix since it is a very uncommon use of the
>function). If you pass a parameter, it won't be passed down to the
>
i have been reading the mail list, and for something that isnt urgent it 
sure comes up an awful lot, i dont think that something like this is a 
big deal as long as users are aware when it would affect them

>
>match="node" template unless you explicitely pass it.
>
>There may be bugs related to result tree fragments, but at least this one
>is not a bug.
>
>Tom.
>_______________________________________________
>xslt mailing list
>xslt@gnome.org
>http://mail.gnome.org/mailman/listinfo/xslt
>
ddupasedm wrote:

running saxon parser
=====================
# alias jxslt='/jdk1.3/bin/java -cp ~/ddupas/xml/sax 
com.icl.saxon.StyleSheet  '

# jxslt any.xml test.xsl
<?xml version="1.0" encoding="utf-8"?><elem_c xmlns:exslt= 
"http://exslt.org/common"; >ORIG_TEXT</elem_c>
<elem_c xmlns:exslt= "http://exslt.org/common"; >OVERRIDE_TEXT</elem_c>

running xsltproc
=================
                   "@>
                "@Ð
                                                     &quot;@_TEXT</text></Ð

# xsltproc  test.xsl any.xml
xmlEncodeEntitiesReentrant : in"@><text>&#136;
<?xml version="1.0"?>       "@Ð
<elem_c>ORIG_TEXT</elem_c><Ð


=== a bit hard to explain, error is xmlEncodeEntitiesReentrant is unhappy

test.xsl
=========


<?xml version= "1.0"?>
<xsl:stylesheet version="1.0"
  xmlns:xsl= "http://www.w3.org/1999/XSL/Transform";
  xmlns:exslt= "http://exslt.org/common";
   >

<xsl:variable  name="base" >
<root > <elem_a>
<elem_b>i am here </elem_b>
</elem_a>
<elem_c>ORIG_TEXT</elem_c>
<elem_d/>
</root>
</xsl:variable>

<xsl:variable  name="merge" >
<root> <elem_a>
<mer_a>TXT</mer_a>
</elem_a>
<elem_c>OVERRIDE_TEXT</elem_c>
</root>
</xsl:variable>

<xsl:template match="text()" />

<xsl:template match="/">
        <xsl:copy-of
                select="exslt:node-set( exslt:node-set($base)//elem_c | 
exslt:node-set($merge)//elem_c) " />

        </xsl:template>

</xsl:stylesheet>

===version info ===

root@c55289-001:~/ddupas/xml/exslt/exsl/functions/node-set# xslt-config 
--version
1.0.4
root@c55289-001:~/ddupas/xml/exslt/exsl/functions/node-set# xml2-config 
--version
2.4.5