Re: [xslt] About bug #62565
- From: darrell dupas <ddupasedm netscape net>
- To: xslt gnome org
- Subject: Re: [xslt] About bug #62565
- Date: Sat, 24 Nov 2001 10:46:00 -0700
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
=================
"@>
"@Ð
"@_TEXT</text></Ð
# xsltproc test.xsl any.xml
xmlEncodeEntitiesReentrant : in"@><text>ˆ
<?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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]