SUBJECT: Xalan-J JIRA defect review - Agenda
WHEN: Monday October 16, 2006 from 2:00 to 3:30 pm EDT
INVITEES: Active Apache Xalan committers
CHAIR: Brian Minchau
WHERE: Teleconference
LAST MEETING WAS ON: Tuesday July
11, 2006
Outline:
0. Roll call
1. Brief Summary of defect arrival
and resolution
2. All open issues with patches or
suggested fixes (30 of them)
3. New Issues Opened Since Last
Meeting (to be triaged)
4. Items from last time
5. Round Table discussion
6. Record of open/re-opened issues
====================================
==================================
0. Roll call
Present:
Brian Minchau
Henry Zongaro
Ilene Seeleman
Kevin Cormier
Santiago Pericas-Geertsen
Yash Talwar
====================================
==================================
1. Brief Summary of defect arrival
and resolution
March 2005 2068-2090 : 23 new
issues
April 2005 2091-2111 : 21 new
issues
May 2005 2112-2132 : 21 new
issues
June 2005 2133-2164 : 32 new
issues
July 2005 2165-2176 : 12 new
issues
August 2005 2177-2192 : 16 new
issues
September 2005 2193-2206 : 14 new
issues
October 2005 2207-2222 : 16 new
issues
November 2005 2223-2240 : 18 new
issues
December 2005 2241-2250 : 10 new
issues
January 2006 2251-2264 : 13 new
issues
February 2006 2265-2273 : 8 new
issues (6 of 8 reported by users)
March 2006 2274-2288 : 12 new
issues (4 of 12 reported by users)
April 2006 2289-2296 : 8 new
issues (4 of 8 reported by users)
May 2006 2297-2298 : 2 new
issues (1 of 2 reported by users)
June 2006 2299-2302 : 4 new
issues (3 of 4 reported by users)
July 2006 2303-2309 : 7 new
issues (5 of 6 reported by users)
August 2006 2310-2315 : 6 new
issues (6 of 6 reported by users)
September 2006 2316-2322 : 7 new
issues (5 of 7 reported by users)
Previous Open or re-opened issue
backlog:
April 5, 2005: 411
May 3, 2005: 409
June 6, 2005: 421
July 12, 2005: 416
February 7, 2006: 446
April 4, 2006: 458
May 2, 2006: 461
July 11, 2006: 463
August 1, 2006: 461
October 14, 2006: 472
====================================
==================================
2. All open issues with patches or
suggested fixes (30 of them)
- - - - - - - - - - - - - - - - - -
Code cleanup patches from Dave
Brosius
2061 - Cleanup some dead code
Brian M. to review/apply
patch.
2208 - removal of some cruft that
does nothing
Brian M. has reviewed and
applied the patch recently.
2209 - invalid code tries to compare
unrelated objects
Henry Z. agreed provide and
alternate patch, and Brian M. will
review it.
2221 - System.arraycopy is more
efficient, so use it
Brian M. has reviewed and
applied the patch recently.
2224 - Switch to use 'new'
collection apis
Brian agreed to review patch.
2236 - clean up static calls thru
instance references
Kevin Cormier agreed to give
a look at the patch,
and Brian M. may give the
formal review/apply of patch.
2242 - wait/notifying on a Thread
object interferes with Thread
Nobody volunteered to review
this one.
2268 - Simplify some dubious URI
code
Henry Z.
reviewed/approved/applied the patch.
2284 - remove needless
synchronization
Henry agreed to review/apply
the patch
Waiting on Xalan PMC to
decide on support 1.2 and up,
and drop support for 1.1.x
2307 - remove some unused code
Brian M. agreed to review the
patch.
Some concerns about remove
code like this: DTM dtm =
xctxt.getDTM(node);
since although the variable
dtm is never used, there may be side
effects.
- - - - - - - - - - - - - - - - - -
1867 - XSLTC: xhtml output method is
not supported, nor does XHTML
doctype sniffing work
Christine Li to review patch.
2078 - MalformedURIException illegal
host (Registry-based Naming
Authority)
Yash T. to come up with
another patch.
2127 - Add support to dynamicly
invoke methods if required.
On Feb 7, 2006 Santiago said
the patch is no longer appropriate,
but that the functionality is
still missing.
Santiago P-G agreed to have
another look at this one.
2133 - XSLTC identity transform
doesn't set all JAXP output
properties
Patch already reviewed, Brian
M. needs to apply it.
2196 - Unneeded BCEL classes in
Xalan.jar (2 jar version)
Henry has reviewed/approved
and applied this change, but more
thorough repackaging/testing
is needed.
2205 - If a URIResolver is provided,
don't call
SystemIDResolver.getAbsoluteURI
Patch already reviewed, Brian
needs to apply it.
2206 - Propagate template inlining
trax attribute
Yash agreed to review patch.
2219 - Namespace of child element
written incorrectly as root
namespace
Yash found a regression,
Brian needs to rework the patch.
The patch in this issue needs
to be reversed and taken out of the
code base.
Somehow it seems that
NamespaceMappings.java in
org.apache.xml.serializer
may already have the fix in
it. This needs to be reviewed by
Brian M.
2222 - Serializer NamespaceMapping
code clarity improvement
Patch already reviewed, Brian
needs to apply it.
No pressing need to act on
this as it changes no functionality.
2239 - add support for exslt.org's
date:date-format extension element
We probably have other
exslt.org extension functions that
we don't support.
For full support we would
need XSLTC and Xalan-C to also
support this.
Need to think about this one.
2240 - Feature URIs are not current
anymore
Patch already reviewed, Brian
to apply it.
2253 -
org.apache.xalan.xsltc.trax.Template
sImpl.newTransformer()
is needlessly synchronized
and causes a bottleneck under
multithreaded load
It would be nice to improve
performance, but developers think
we've
already minimized our
sychronization blocks, further
reduction might
be getting peformance gains
at the risk of introducing bugs.
2264 - Supporting xi:include (and
other factory features) on xalan
Process command-line
One can write a Java program,
create an instance of the XML parser
with
xi:include enabled and pass
it into the transformer, so
supporting this with
the Process command-line is
not high priority.
2297 - URIResolver passed wrong base
URI for nested include/import
Patch already reviewed, needs
to be applied by Brian M.
2301 - NPE in ElemTemplateElement
for a ElemSort as part of an
ElemForEach
when dynamically generating a
Templates
... forgot to review this
one.
2302 - Prefix collision bug during
serialization
Yash agreed to review the
patch.
2309 - DOMResult should be able to
create entity references
Henry Z. agreed to
look/evaluate this to see what is
going on.
2316 -
WriterToUTF8Buffered.write(String s)
fail with big strings
Kevin C. (a contributor)
agreed to reproduce this problem
and check the patch. He is
not a committer so ultimately he
will get Brian M. to give the
official
review/approval/application.
2317 - Command line XSLTC 2.7.0
swallows error diagnostics
Santiago P-G agreed to look
at this one.
2321 - Multi-threading problem with
AVTs
Yash T. agreed to review this
issue.
2325 - XSLTC Causes NoSuchFieldError
if global variable is unused
Santiago P-G agreed to review
the patch and see if it is robust.
If the patch is not good then
it will probably not be re-worked.
====================================
==================================
3. New Issues Opened Since Last
Meeting (to be reviewed)
2306 - Entities are not resolved
properly if document instances of a
DTD with different internal
subsets are loaded recursively
No volunteers to proceed on
this one.
2307 - [PATCH] remove some unused
code
This issue and patch provided
are a duplicate of
2208 which was recently
applied to the code base.
2308 - Nodes in a node set created
using the node-set extension
function are not accessible
through key
Though Henry Z. opened this
issue he is not the real originator.
This functionality seems to
be available in XSLT 2.0 so this is
the motivation for this
issue. However Henry Z. doesn't
think this
is a high priority issue.
2310 - StackOverFlow during large
file transformation (works in
saxon-8-7-3b)
Suggest user use -Xss JVM
option to set a larger stack size.
2311 - Wrong error about missing
template
Kevin C. will try to
reproduce and see if a more accurate
error
message can be produced.
2312 - Exception thrown in
ErrorListener.warning() swallowed by
org.apache.xml.serializer.ToXMLStrea
m.addAttribute()
Brian M. agreed to look at
this one and ask for a testcase.
2313 - XSLTC must reports about
fatal error if can't compile
JAXP 1.3 was ambiguous about
whether a processor was
supposed to leave error
handling to the user installed
error handler, but if there
was no user error handler
then the default error
handler was not permitted to
throw
TransformerConfigurationException-s
for errors
fatal errors. In JAXP 1.4
things were clarified to say
the the default error handler
can throw exceptions when
a fatal error occurs.
Some concern about whether
this will change the behavior
and may have backward
compatibility issues.
Not planning to proceed on
this one.
2314 - Exceptions not been thrown
for transformation errors
Henry Z. agreed to look at
this one.
2315 - MethodResolver.convert
converts CharSequence into Double
Brian M. agreed to look at
this one, but is requesting
a testcase from the reporter.
2319 - Descendant axis sometimes
includes the context node
Brian M. agreed to look at
this one.
2320 - Excluding result prefix of a
namespace not declared caused NPE
Brian M. ran the testcase
with the current development code.
A good error message is
produced, no NPE. The issue is
resolved.
2322 - CLONE -Data corrupted in
Parallel XSL execution
(when calling Extension
Function)
(
https://issues.apache.org/jira/brows
e/XALANJ-2083)
The reporter has said that the
patch in XALANJ-2321 fixes his
problem
so this issue will be resolved
and marked as a duplicate of that
one.
2323 - closeStartTag() in
ToHTMLSAXHandler does not pass
localName or
namespace to the
ContentHandler. Results in
ValidationException
in Apache FOP.
ToTextSAXHandler consumes all
startElement
and endElement events because
it "knows" that the final stream
serializer will consume them
rather than emit something for them
into the stream of bytes.
This was an optimization.
ToHTMLSAXHandler
does similar. However this is
in violation of JAXP 1.3, as the
events ought to be passed
further down the line (the user may
have their own ContentHandler
to accept SAX events for serializing
text output).
Suggest that ToHTMLSAXHandler
and ToTextSAXHandler be deprecated,
and that only ToXMLSAXHandler
be used in the future.
2326 - XSLTC generates prefixes that
are too unique
Not a high priority.
====================================
==================================
3. Items from last time
(This section was not discussed at
the meeting)
2260 - Henry Z. agreed to look at
this one.
2262 - Brian to look at throwing the
exception, rather than
ignoring it.
2291 - opened by Brian M. ... should
be assigned to Brian
2299 - assigned to Yash (any
progress?)
2305 - Brian M. will have a look at
this one
====================================
==================================
4. Round Table discussion
Possible 2.7.1 release (assuming the
PMC votes for it)
Documenting a process for creating a
new release
- build
- package
- test
- distribute
- website updates
It was suggested that the process to
create a new release be
integrated into the existing
web-pages as opposed to some side
files.
Yash agreed to provide content for
build and package.
Brian agreed to provide content for
package distribution and
website publishing.
====================================
==================================
5. Record of open/re-opened issues
14
18
19
32
36
47
65
67
77
101
111
121
123
169 - Triaged Oct 15, 2001
203
207
232
238
287
291
306
342
391
403
476
540
566
575 - Triaged October 15, 2001
590
605
656
662
666
667
717
718
722
726
738
739
742
745
757
762
763
781
784
797
801
803
808
816
817
834
838
862
888
889
891
896
909
915
916
917
920
923
927
931
942
953
954
955
962
969
979
984
988
989
990
1001
1007
1028
1029
1042
1043
1065
1072
1074
1080
1081
1083
1084
1086
1087
1089
1097
1102
1103
1104
1117
1122
1125
1127
1139
1143
1151
1160
1164
1168
1183
1184
1189
1194
1205
1208
1219
1229
1240
1241
1243
1260
1263
1264
1281
1286
1290
1296
1308
1316
1317
1319
1326
1334
1335
1339
1344
1345
1347
1348
1352
1353
1357
1361
1363
1364
1369
1371
1372
1384
1385
1401
1402
1406
1408
1410
1433
1434
1443
1444
1446
1447
1462
1463
1468
1470
1473
1474
1477
1482
1485
1491
1492
1499
1500
1502
1508
1511
1522
1534
1536
1546
1547
1549
1552
1565
1574
1575
1576
1577
1601
1608
1618
1621
1625
1628
1630
1638
1639
1650
1651
1652
1661
1669
1671
1673
1676
1683
1685
1686
1688
1689
1694
1695
1698
1718
1719
1725
1733
1742
1748
1752
1764
1766
1767
1769
1770
1773
1774
1781
1784
1785
1787
1788
1790
1791
1793
1795
1798
1802
1804
1807
1808
1812
1813
1819
1821
1823
1825
1826
1827
1828
1831
1839
1841
1846
1847
1848
1849
1850
1851
1855
1856
1862
1867
1868
1872
1874
1875
1880
1883
1884
1889
1890
1898
1899
1900
1901
1902
1905
1906
1908
1911
1913
1919
1921
1927
1928
1929
1930
1931
1932
1933
1936
1939
1945
1948
1949
1950
1951
1952
1953
1957
1958
1959
1960
1961
1962
1968
1969
1972
1973
1974
1975
1976
1983
1984
1987
1991
1992
1995
1996
2000
2001
2010
2014
2020
2022
2024
2028
2031
2032
2039
2050
2056
2057
2061 - Triaged October 16, 2006
2062
2063
2067
2071
2072
2078 - Triaged October 16, 2006
2088
2091
2092
2094
2100
2106
2107
2108 - Triaged April 4, 2006
2111
2112
2113 - Triaged May 3, 2005
2118
2119
2127 - Triaged February 7, 2006 -
Triaged October 16, 2006
2130 - Triaged February 7, 2006
2133 - Triaged February 7, 2006 -
Triaged October 16, 2006
2137
2150
2151
2152
2153
2155
2157 - Triaged February 7, 2006
2160
2165
2166
2168 - Triaged March 7, 2006
2169
2171
2173
2177
2178
2180
2186
2188
2189
2190
2191
2192
2193
2194
2195
2196 - Triaged February 7, 2006 -
Triaged October 16, 2006
2197
2198
2200
2201
2202
2203
2204
2205 - Triaged February 7, 2006 -
Triaged October 16, 2006
2206 - Triaged October 16, 2006
2208 - Triaged October 16, 2006
2209 - Triaged October 16, 2006
2210
2211
2212
2215
2216
2219 - Triaged October 16, 2006
2221 - Triaged February 7, 2006
2222 - Triaged February 7, 2006 -
Triaged October 16, 2006
2223
2224 - Triaged February 7, 2006 -
Triaged October 16, 2006
2225
2227
2228
2229
2233
2234
2236 - Triaged October 16, 2006
2238
2239 - Triaged October 16, 2006
2240 - Triaged February 7, 2006 -
Triaged October 16, 2006
2241
2242
2244
2246
2247
2248
2252
2253 - Triaged February 7, 2006 -
Triaged October 16, 2006
2254
2255
2256
2257
2258
2259 - Triaged April 4, 2006
2260 - Triaged July 11, 2006
2261 - Triaged July 11, 2006
2262 - Triaged July 11, 2006
2264 - Triaged February 7, 2006 -
Triaged October 16, 2006
2265 - Triaged April 4, 2006
2266 - Triaged April 4, 2006
2268 - Triaged March 7, 2006 -
Triaged October 16, 2006
2270 - Triaged March 7, 2006
2274 - Triaged March 7, 2006
2279 - Triaged April 4, 2006
2280 - Triaged April 4, 2006
2282 - Triaged April 4, 2006
2283 - Triaged April 4, 2006
2284 - Triaged April 4, 2006 -
Triaged October 16, 2006
2286 - Triaged April 4, 2006
2287 - Triaged April 4, 2006
2288 - Triaged April 4, 2006
2291 - Triaged July 11, 2006
2296 - Triaged July 11, 2006
2297 - Triaged July 11, 2006 -
Triaged October 16, 2006
2299 -
2301 - Triaged July 11, 2006
2302 - Triaged July 11, 2006 -
Triaged October 16, 2006
2305 - Triaged July 11, 2006
2306
2307 - Triaged October 16, 2006
2308 - Triaged October 16, 2006
2309 - Triaged October 16, 2006
2310 - Triaged October 16, 2006
2311 - Triaged October 16, 2006
2312 - Triaged October 16, 2006
2313 - Triaged October 16, 2006
2314 - Triaged October 16, 2006
2315 - Triaged October 16, 2006
2316 - Triaged October 16, 2006
2317 - Triaged October 16, 2006
2319 - Triaged October 16, 2006
2320 - Triaged October 16, 2006
2321 - Triaged October 16, 2006
2322 - Triaged October 16, 2006
2323 - Triaged October 16, 2006
2325 - Triaged October 16, 2006
2326 - Triaged October 16, 2006
====================================
==================================
6. Record of previously triaged
issues
2032-2112
2113-2126
Hi, Mike. Mike Brown <mi...@skew.org> wrote on 2006-10-18 12:34:13 PM: > Henry Zongaro wrote: > > I just wanted to clarify the remarks that I made during the defect review > > meeting. Another user ran into this problem trying to do the same sort of > > things with the node-set function key, and that's why I opened the Jira > > issue. What I said about XSLT 2.0 was that the fact that it allows the > > key function to return nodes from temporary trees would be an argument in > > favour of doing the same thing in XSLT 1.0 if the key function is > > evaluated with a context node that is in a tree returned by the node-set > > extension function. > > Thanks for that explanation, but it still sounds like you're under the > impression that supporting keys on converted result tree fragments /temporary > trees is an enhancement or questionable interpretation of XSLT 1.0. > > It's true the spec is a little loose with its use of the term "document" at > times, but it is very clear about the fact that it operates on the XPath/XSLT > node tree models only. > > I don't think it's a stretch to say that a root node "is" a document, in this > model. So, once the fragment becomes a real node-set consisting of a single > root node, it is indistinguishable from any other document, as far as the > processor is concerned. That it was generated internally and not obtained from > parsing a byte stream isn't relevant. > > Given the way key() is specified, then, it is reasonable to expect that a > conforming XSLT 1.0 processor, for purposes of keys, would treat it no > differently than any other. What XSLT 2.0 does is immaterial. > > > So, I would consider it higher priority than a feature request; it's a real > implementation gap, if not a "bug". However, there are generally workarounds > (inefficient) for most key-related operations, so it's not as high a priority > as other issues. I think that when I originally opened the issue, I regarded it as a bug. When I spoke during the defect review call, I think I regarded it as an enhancement. You've convinced me that it is, in fact, a bug; a processor that supports the node-set extension should permit the key function to retrieve nodes in the tree returned by node-set. Thanks, Henry ------------------------------------------------------------------ Henry Zongaro XSLT Processors Development IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044 mailto:zongaro@ca.ibm.com --------------------------------------------------------------------- To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org For additional commands, e-mail: xalan-dev-help@xml.apache.org
Hi, Mike. Mike Brown <mi...@skew.org> wrote on 2006-10-18 12:34:13 PM: > Henry Zongaro wrote: > > I just wanted to clarify the remarks that I made during the defect review > > meeting. Another user ran into this problem trying to do the same sort of > > things with the node-set function key, and that's why I opened the Jira > > issue. What I said about XSLT 2.0 was that the fact that it allows the > > key function to return nodes from temporary trees would be an argument in > > favour of doing the same thing in XSLT 1.0 if the key function is > > evaluated with a context node that is in a tree returned by the node-set > > extension function. > > Thanks for that explanation, but it still sounds like you're under the > impression that supporting keys on converted result tree fragments /temporary > trees is an enhancement or questionable interpretation of XSLT 1.0. > > It's true the spec is a little loose with its use of the term "document" at > times, but it is very clear about the fact that it operates on the XPath/XSLT > node tree models only. > > I don't think it's a stretch to say that a root node "is" a document, in this > model. So, once the fragment becomes a real node-set consisting of a single > root node, it is indistinguishable from any other document, as far as the > processor is concerned. That it was generated internally and not obtained from > parsing a byte stream isn't relevant. > > Given the way key() is specified, then, it is reasonable to expect that a > conforming XSLT 1.0 processor, for purposes of keys, would treat it no > differently than any other. What XSLT 2.0 does is immaterial. > > > So, I would consider it higher priority than a feature request; it's a real > implementation gap, if not a "bug". However, there are generally workarounds > (inefficient) for most key-related operations, so it's not as high a priority > as other issues. I think that when I originally opened the issue, I regarded it as a bug. When I spoke during the defect review call, I think I regarded it as an enhancement. You've convinced me that it is, in fact, a bug; a processor that supports the node-set extension should permit the key function to retrieve nodes in the tree returned by node-set. Thanks, Henry ------------------------------------------------------------------ Henry Zongaro XSLT Processors Development IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044 mailto:zongaro@ca.ibm.com
Henry Zongaro wrote: > I just wanted to clarify the remarks that I made during the defect review > meeting. Another user ran into this problem trying to do the same sort of > things with the node-set function key, and that's why I opened the Jira > issue. What I said about XSLT 2.0 was that the fact that it allows the > key function to return nodes from temporary trees would be an argument in > favour of doing the same thing in XSLT 1.0 if the key function is > evaluated with a context node that is in a tree returned by the node-set > extension function. Thanks for that explanation, but it still sounds like you're under the impression that supporting keys on converted result tree fragments / temporary trees is an enhancement or questionable interpretation of XSLT 1.0. It's true the spec is a little loose with its use of the term "document" at times, but it is very clear about the fact that it operates on the XPath/XSLT node tree models only. I don't think it's a stretch to say that a root node "is" a document, in this model. So, once the fragment becomes a real node-set consisting of a single root node, it is indistinguishable from any other document, as far as the processor is concerned. That it was generated internally and not obtained from parsing a byte stream isn't relevant. Given the way key() is specified, then, it is reasonable to expect that a conforming XSLT 1.0 processor, for purposes of keys, would treat it no differently than any other. What XSLT 2.0 does is immaterial. So, I would consider it higher priority than a feature request; it's a real implementation gap, if not a "bug". However, there are generally workarounds (inefficient) for most key-related operations, so it's not as high a priority as other issues. Thanks, Mike
Hi, Mike. Mike Brown <mi...@skew.org> wrote on 2006-10-17 06:59:39 PM: > Brian Minchau wrote: > > 2308 - Nodes in a node set created > > using the node-set extension > > function are not accessible > > through key > > Though Henry Z. opened this > > issue he is not the real originator. > > This functionality seems to > > be available in XSLT 2.0 so this is > > the motivation for this > > issue. However Henry Z. doesn't > > think this > > is a high priority issue. > > Well, I have real XSLT 1.0 code that is impacted by this today. I have to > completely avoid using Muenchian grouping when operating on generated > node-sets because of it. > > Also, it's not just XSLT 2.0 functionality. I just wanted to clarify the remarks that I made during the defect review meeting. Another user ran into this problem trying to do the same sort of things with the node-set function key, and that's why I opened the Jira issue. What I said about XSLT 2.0 was that the fact that it allows the key function to return nodes from temporary trees would be an argument in favour of doing the same thing in XSLT 1.0 if the key function is evaluated with a context node that is in a tree returned by the node-set extension function. The particular user opted to write their stylesheet in a different way, so I indicated this wasn't a high priority. If you feel this is a critically important feature, maybe we should look at fixing this in Xalan-J 2.7.1. Thanks, Henry ------------------------------------------------------------------ Henry Zongaro XSLT Processors Development IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044 mailto:zongaro@ca.ibm.com
Hi, Mike. Mike Brown <mi...@skew.org> wrote on 2006-10-17 06:59:39 PM: > Brian Minchau wrote: > > 2308 - Nodes in a node set created > > using the node-set extension > > function are not accessible > > through key > > Though Henry Z. opened this > > issue he is not the real originator. > > This functionality seems to > > be available in XSLT 2.0 so this is > > the motivation for this > > issue. However Henry Z. doesn't > > think this > > is a high priority issue. > > Well, I have real XSLT 1.0 code that is impacted by this today. I have to > completely avoid using Muenchian grouping when operating on generated > node-sets because of it. > > Also, it's not just XSLT 2.0 functionality. I just wanted to clarify the remarks that I made during the defect review meeting. Another user ran into this problem trying to do the same sort of things with the node-set function key, and that's why I opened the Jira issue. What I said about XSLT 2.0 was that the fact that it allows the key function to return nodes from temporary trees would be an argument in favour of doing the same thing in XSLT 1.0 if the key function is evaluated with a context node that is in a tree returned by the node-set extension function. The particular user opted to write their stylesheet in a different way, so I indicated this wasn't a high priority. If you feel this is a critically important feature, maybe we should look at fixing this in Xalan-J 2.7.1. Thanks, Henry ------------------------------------------------------------------ Henry Zongaro XSLT Processors Development IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044 mailto:zongaro@ca.ibm.com --------------------------------------------------------------------- To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org For additional commands, e-mail: xalan-dev-help@xml.apache.org
Brian Minchau wrote: > 2308 - Nodes in a node set created > using the node-set extension > function are not accessible > through key > Though Henry Z. opened this > issue he is not the real originator. > This functionality seems to > be available in XSLT 2.0 so this is > the motivation for this > issue. However Henry Z. doesn't > think this > is a high priority issue. Well, I have real XSLT 1.0 code that is impacted by this today. I have to completely avoid using Muenchian grouping when operating on generated node-sets because of it. Also, it's not just XSLT 2.0 functionality. XSLT 1.0 says that key() has to return nodes from "the same document as" the context node, and XSLT 1.0 operates on "document" which is modeled as a slightly modified XPath node tree, always having a root node under which all the other nodes fall and thus comprise part of the same document as the root node. A converted result tree fragment is a node-set that contains a single root node. Unless otherwise stated, document identity is going to be based on the root node. So, regardless of whether your context node is from a converted result tree fragment, it stands to reason that the context node itself, as well as any other nodes under the same root, would be potential members of the node-set returned by key().