Re: [xslt] About bug #62565

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 .. ... wrote:

>Hi all,
>Bug #62565 is available at <>
>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.
>xslt mailing list
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= 
""; >ORIG_TEXT</elem_c>
<elem_c xmlns:exslt= ""; >OVERRIDE_TEXT</elem_c>

running xsltproc

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

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


<?xml version= "1.0"?>
<xsl:stylesheet version="1.0"
  xmlns:xsl= "";
  xmlns:exslt= "";

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

<xsl:variable  name="merge" >
<root> <elem_a>

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

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



===version info ===

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]