gmesch / ajaxslt Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/ajaxslt
License: Other
Automatically exported from code.google.com/p/ajaxslt
License: Other
The XPath spec says that a node-set is "an unordered collection of nodes
without duplicates". In certain situations, we're not removing duplicates
in the node-sets. If I'm not mistaken, the following two expressions should
return identical node-sets:
/descendant-or-self::*/A
/descendant::A/../A
However, the second expression returns duplicates in its node-set (example
page:
http://code.google.com/p/jsprofile/source/browse/trunk/test/functional/ajaxslt/n
ews.google.com.html)
We can take a look at how other engines (i.e. cybozu) detect duplicates;
comparing nodes using "===" is non-performant.
Original issue reported on code.google.com by [email protected]
on 26 Jun 2008 at 2:10
What steps will reproduce the problem?
1. XML document
<page>
<message>
Hello World.
</message>
</page>
2. XSL transformation
<xsl:stylesheet>
<xsl:template match="/page">
<xsl:apply-templates select="message"/>
</xsl:template>
<xsl:template match="message">
<div style="color:green">
<xsl:value-of select="."/>
</div>
</xsl:template>
</xsl:stylesheet>
What is the expected output? What do you see instead?
I expected the output to be equivalent to the test example, that is:
<div style="color:green">
Hello World.
</div>
However, the actual output is empty.
What version of the product are you using? On what operating system?
ajaxslt-0.7 and ajaxslt svn
Microsoft Windows XP SP2
Firefox 2.0.0.1
Microsoft Internet Explorer 6
Please provide any additional information below.
<xsl:template match="*|/">
<xsl:apply-templates/>
</xsl:template>
( see http://www.w3.org/TR/xslt#built-in-rule )
Adding this equivalent of the built-in template rule that should apply to
allow recursive processing to continue in the absence of a successful
pattern match by an explicit template rule in the stylesheet produces :
<div style="color:green">
Hello World.
</div>
<div style="color:green">
Hello World.
</div>
I attached builtin.xml that refers to builtin.xsl. Opening builtin.xml in
firefox or internet explorer produces the expected result.
Thank you.
G.
Original issue reported on code.google.com by [email protected]
on 10 Feb 2007 at 6:02
Attachments:
I hit some of the "not implemented yet" items and a few others I spotted
before deciding that this probably doesn't suit my purposes. Still, the
changes I've made may prove useful to you (or not), so here they are.
TODO Items done:
local-name
namespace-uri
xsl:message
Bug in translate function.
To reproduce:
1. run stylesheet that will do translate('abc','aba','xaz')
Expected output is string 'xac' as spec says "If a character occurs more
than once in the second argument string, then the first occurrence
determines the replacement character". Instead output is "xzc" (string gets
changed first to "xbc" then "xac" and then "xzc").
XPath extensions for XSLT that were are not supported:
current
document (support added is not complete - also could fail on some
platforms, but will report this through a call to function-available properly.)
element-available
function-available
generate-id
system-property
Still not supported, but now report their not-implemented status:
format-number
key
Calls to empty function xpathLog do nothing. Replace with commented out;
someone implementing xpathLog can also do a find and replace to turn
"//xpathLog" to "xpathLog".
Original issue reported on code.google.com by [email protected]
on 21 May 2007 at 5:20
Attachments:
What steps will reproduce the problem?
1. Use an xpath expression that has a variable containing a node list.
2. Reference a child of this node list using the absolute '/' operator
3. JS exception is thrown about how the expression can't be parsed.
What is the expected output? What do you see instead?
Expect to see the string $var/foo parsed. Instead a js exception is thrown.
What version of the product are you using? On what operating system?
Tried using the latest from trunk (ajaxslt v7) still an issue. OS X 10.4
Please provide any additional information below.
Stepping through the source with a js debugger the issue is resolving
precedence with the '/' operator. In the xpathTokenRules object, '//' has a
prec of 19 and '/' of 30. Inside of xpathReduce() when calculating the prec
of the candidate and ahead, will fail to pop the stack. It is comparing the
prec of XPathFilterExpr which is set to 20 and '/' which is 30.
Modifying line 1927:
[ XPathFilterExpr, [ XPathPrimaryExpr, XPathPredicate, Q_MM ], 31,
makeFilterExpr ],
to use a prec value of 31 instead of 20 solved the issue for me and allowed
the expression to be parsed. However I am not sure of all the consequences
of changing this prec value.
Original issue reported on code.google.com by [email protected]
on 29 Jan 2007 at 6:31
What steps will reproduce the problem?
See the file attached and test it on
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 21 Jul 2009 at 1:48
What steps will reproduce the problem?
1. Evaluate an expression of the form: ../principal * instance('rate')
('instance' is an XPath function specific to XForms but any function call
will exhibit the same behavior). The inverse, FunctionCall * LocationPath,
will fail as well.
What is the expected output? What do you see instead?
The expected output is the value of the node selected by the location expr
multiplied by the result of the function call expr. The actual result is
an xpath parse error because the stack contains two Expr objects.
What version of the product are you using? On what operating system?
ajaxslt-0.8.1, Windows XP.
Please provide any additional information below.
The Ubiquity XForms project is using ajaxslt and this issue was discovered
using one of our sample forms. The relative location path is fully reduced
to an Expr but there is no rule for an Expr followed by TOK_ASTERISK and
the asterisk is lost. The following function call is also fully reduced to
an Expr but now you have two Expr objects left on the stack.
Adding the rule: [ XPathExpr, [ XPathExpr, TOK_ASTERISK], 0, passExpr,
ASSOC_LEFT ] to xpathGrammarRules solved the problem for us. A patch with
that one simple change is attached.
Original issue reported on code.google.com by [email protected]
on 28 Aug 2008 at 7:16
Attachments:
http://sourceforge.net/tracker/index.php?func=detail&aid=1596549&group_id=140999
&atid=748120
Original issue reported on code.google.com by [email protected]
on 15 Dec 2006 at 9:25
What steps will reproduce the problem?
xsltProcess() cannot transform the attached xml file with the xsl file
attached. Both these file works in Stylus and firefox.
The <xsl:value of select="tagname[@id='id']/@name" /> statements cannot be
executed successfully.
What is the expected output? What do you see instead?
Try to reproduce with the attachment.
What version of the product are you using? On what operating system?
AJAXSLT 0.7
Firefox under Windows XP SP2.
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 13 Nov 2007 at 9:38
Attachments:
Change the 'xsltProcess' function to the following to support passing a
hash of parameters as third parameter to this function:
function xsltProcess(xmlDoc, stylesheet, params) {
var output = domCreateDocumentFragment(new XDocument);
var c = new ExprContext(xmlDoc);
if(params) {
for(var p in params)
c.setVariable(p, new StringValue(params[p]));
}
xsltProcessContext(c, stylesheet, output, params);
var ret = xmlText(output);
return ret;
}
Original issue reported on code.google.com by [email protected]
on 23 Oct 2007 at 12:01
https://sourceforge.net/tracker/index.php?func=detail&aid=1459468&group_id=14099
9&atid=748118
Original issue reported on code.google.com by [email protected]
on 15 Dec 2006 at 9:59
What steps will reproduce the problem?
1. use the sample code that comes with ajaxslt with one modification on the
xml that follows:
<page>
<message><![CDATA[
<b>Hello</b> World.
]]></message>
</page>
2. Run it through AJAXSLT
What is the expected output? What do you see instead?
The expected output should be this:
<div style="color:green">
<b>Hello</b> World.
</div>
However the acutal output is this:
<div style="color:green">
<b>Hello</b> World.
</div>
What version of the product are you using? On what operating system?
I am using version 0.5 on a PC.
Please provide any additional information below.
Maybe I am not doing it correctly. If I am not please point out what I am
doing wrong.
Original issue reported on code.google.com by [email protected]
on 2 Dec 2006 at 12:34
What steps will reproduce the problem?
1. Download the ajaxslt package.
2. Run the xpath.html file in IE6/7, safari, and firefox.
3. Get the error on load.
What is the expected output? What do you see instead?
I would expect to see a successful parsing of the files, instead I am
shown a Error when I click on parse.
Error "this.nodetest.parsetree is not a function" is the result I get on
Firefox on linux. IE6 on winxp I get "xpath parse error: stack exception
xpath parse error". Safari 2.0.4 on OSX 10.4 PPC I get "EXCEPTION
TypeError - Undefined Value"
What version of the product are you using? On what operating system?
See message above.
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 18 Jan 2007 at 8:25
What steps will reproduce the problem?
<a>
<xsl:attribute name="href">
test.php?test
</xsl:attribute>
<xsl:attribute name="target">mainframe</xsl:attribute>
test
</a>
What is the expected output? What do you see instead?
<a href="test.php?test" target="mainframe">test</a>
What version of the product are you using? On what operating system?
8.1
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 27 Apr 2008 at 12:54
Selenium bugs SEL-444 and SEL-486 can be reproduced using the following
xpaths:
id('nested1')/div[1]//input[2]
id('foo')//div[contains(@id, 'useful')]//input
More detail is available in Selenium JIRA.
http://jira.openqa.org/browse/SEL-444
http://jira.openqa.org/browse/SEL-486
Original issue reported on code.google.com by [email protected]
on 5 Nov 2007 at 4:08
https://sourceforge.net/tracker/index.php?func=detail&aid=1508596&group_id=14099
9&atid=748118
Original issue reported on code.google.com by [email protected]
on 15 Dec 2006 at 10:06
What steps will reproduce the problem?
1. Create a xsl that uses the document function to include some external
xml (see attached files)
What is the expected output?
Standard:
Working :)
Document function:
Working :)
What do you see instead?
I get an uncaught exception in firefox that I haven't been able to locate
the source of.
What version of the product are you using? On what operating system?
ajaxslt-0.8.1
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 11 Sep 2008 at 4:06
Attachments:
strip-space is not implemented
Original issue reported on code.google.com by [email protected]
on 31 May 2009 at 2:37
Found when fixing
https://sourceforge.net/tracker/index.php?func=detail&aid=1459468&group_id=14099
9&atid=748118
Original issue reported on code.google.com by [email protected]
on 18 Dec 2006 at 6:51
What steps will reproduce the problem?
1. Create an XML fragment with an Axis specifier as a node name e.g.
parent, child etc...
2. Create an XSL template with an Xpath Query which selects based on node
name. e.g. <xsl:value-of select="//child"/>
3. The Xpath doesn't output any results and the js method reports no
exception or handled exceptions.
Attached is the source with a HTML page in the test folder. This should
help recreate the fault.
What is the expected output? What do you see instead?
I would expect to see the XSLT to output the result of the xsl:value-of
select when using 'child' in the expression.
What version of the product are you using? On what operating system?
ajaxslt0.8.1, Windows XP SP2, Mozilla Firefox 3.5.5
Please provide any additional information below.
I think the problem is 'child' and 'parent' are considered delimited node
names within an xpath. However they only become delimited when the '::'
double colon is used. Otherwise they should be considred a qualified name
(QName) rather tthan an Axis specifier.
Original issue reported on code.google.com by [email protected]
on 8 Dec 2009 at 12:10
Attachments:
What steps will reproduce the problem?
1. trying to transfrom this xml:
<?xml version="1.0" encoding="UTF-8"?>
<page xmlns="AA">
Hello World!
</page>
2. using this xslt:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:aa="AB">
<xsl:template match="/">
<xsl:apply-templates/>
</xsl:template>
<xsl:template match="aa:page">
<xsl:value-of select="."/>
</xsl:template>
</xsl:stylesheet>
I expect to see:
Hellow world!
But result is empty.
What version of the product are you using? On what operating system?
MsWindows XP SP 2
Opera 9.26
FF 2.0.0.12
ajaxslt-0.8.1.tar.gz
Please provide any additional information below.
Another view on the same bug:
lets transform following xml:
<?xml version="1.0" encoding="UTF-8"?>
<aa:page xmlns:aa="AA"> <!-- AA namespace -->
Hello World!
</aa:page>
with following xslt:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:aa="ZZ"> <!-- ZZ namespace -->
<xsl:template match="/">
<xsl:apply-templates/>
</xsl:template>
<xsl:template match="aa:page">
<xsl:value-of select="."/>
</xsl:template>
</xsl:stylesheet>
Expected result: Empty, because namespaceses actually are different.
Actual result: Hello World!
It looks like engine doesn't handle namespace prefixes at all, treating
them just as begining of tags names.
Original issue reported on code.google.com by [email protected]
on 13 Mar 2008 at 3:56
What steps will reproduce the problem?
1. Test the xmlEscapeText function with this string: Im <b>bold</b>!
What is the expected output? What do you see instead?
I expect it to produce: Im <b>bold</b>!
However this is what is produced: Im <b>bold</b>!
What version of the product are you using? On what operating system?
I am using version 0.5 on a PC.
Please provide any additional information below.
I believe that the function needs to be modifed from this:
function xmlEscapeText(s) {
return ('' + s).replace(/&/, '&').replace(/</, '<').
replace(/>/, '>');
}
To this:
function xmlEscapeText(s) {
return ('' + s).replace(/&/g, '&').replace(/</g, '<').
replace(/>/g, '>');
}
That way all the < & and > are found in the string.
I dont know if this is the behavior that you are wanting.
Original issue reported on code.google.com by [email protected]
on 3 Dec 2006 at 5:39
Run the xmltoken_unittest.html on Safari. testXmlName11 will fail on #27.
(I don't really understand what this test is attempting to cover... what is
being verified here?)
Tested on Safari 3.0.4 Beta on Windows, Safari 3 for OS X 10.4 (Tiger) and
Safari 2 for OS X 10.4.
Original issue reported on code.google.com by [email protected]
on 16 Nov 2007 at 7:10
As implemented, in an HTML xpath like "//div", xpath.js attempts to
recursively collect all descendants before running the node test. This
performs slowly because it will first attempt to iterate through every
child node in the document, and only then filter out those that are not divs.
Applying the nodetest earlier would help, but it's even better to run the
universal JS function written in C to do precisely this: getElementsByTagName.
I've attached a patch that will handle this case. Instead of blindly
recursively collecting descendants, we attempt to extract a tag name from
the node test if possible. (If the node test is NodeTestName, use the
name; if it's NodeTestAny or NodeTestElementOrAttribute, use "*".) Then we
skip the node test loop at the end of StepExpr, in order to avoid
needlessly cloning the context.
To make this work, I had to do a bit of fancy footwork in the parser as
well. As currently implemented, gathering descendants happens in one step,
and then running the node test happens in a following step (on the child
axis). I modified makeLocationExpr2, makeLocationExpr7 and makePathExpr2
to unify cases like these into a single step that applies the nodetest on
the descendant-or-self axis.
This patch is more ambitious than some of the others, so I'm not checking
it in right away... I'd like someone to code review it before I apply it.
On my machine it results in a big performance increase; 70% in some cases.
Original issue reported on code.google.com by [email protected]
on 6 Nov 2007 at 12:56
Attachments:
http://sourceforge.net/tracker/index.php?func=detail&aid=1583867&group_id=140999
&atid=748120
Original issue reported on code.google.com by [email protected]
on 15 Dec 2006 at 9:26
https://sourceforge.net/tracker/index.php?func=detail&aid=1345368&group_id=14099
9&atid=748118
n its simplest form, "<xsl:apply-templates />" with no
arguments does not work as expected. From the w3c: "In
the absence of a select attribute, the
xsl:apply-templates instruction processes all of the
children of the current node, including text nodes."
Currently the "select" attribute must be specified.
Original issue reported on code.google.com by [email protected]
on 15 Dec 2006 at 9:43
What steps will reproduce the problem?
1. Have the following HTML file:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<script src="http://ajaxslt.googlecode.com/svn/tags/release-0-8-1/xmltoken.js"></script>
<script src="http://ajaxslt.googlecode.com/svn/tags/release-0-8-1/util.js"></script>
<script src="http://ajaxslt.googlecode.com/svn/tags/release-0-8-1/dom.js"></script>
<script src="http://ajaxslt.googlecode.com/svn/tags/release-0-8-1/xpath.js"></script>
<script>
function tryMe() {
var expr = xpathParse("/html/body/h1");
var result = expr.evaluate(new ExprContext(document));
var s = result.nodeSetValue();
alert(s.length);
}
window.onload = tryMe;
</script>
</head>
<body>
<h1>Test</h1>
</body>
</html>
2. Open this file in your browser
What is the expected output? What do you see instead?
The expected output is '1', but 0 results are found using this XPath ("//h1"
works just fine).
What version of the product are you using? On what operating system?
I'm using version 0.8.1.
Original issue reported on code.google.com by [email protected]
on 29 May 2011 at 9:18
What steps will reproduce the problem?
1. Produce two XDocument instances
2. Clone (make a copy of) a node from one document
3. Invoke appendChild, replaceChild or insertBefore to place the clone in
the second document.
What is the expected output?
When the cloned node is placed in the new document, its ownerDocument
should be the new document.
What do you see instead?
The ownerDocument is still the old document.
What version of the product are you using?
Up to at least r61
On what operating system?
All.
Please provide any additional information below.
Some XPath evaluations, e.g. absolute ones, request the ownerDocument of a
node, at which point you end up in the wrong document.
Original issue reported on code.google.com by [email protected]
on 28 Feb 2009 at 11:24
http://www.llamalab.com/js/xpath/benchmark.html lists a number of JS tests.
We're doing quite well on performance, but we disagree with FF's native
XPather on a number of tests
descendant::node()
native returns 248 nodes
ajaxslt returns 88 nodes
//LI[1]
native returns 2 nodes
ajaxslt returns 1 node
//LI[last()]/text()
native returns 2 nodes
ajaxslt returns 1 node
//LI[position() mod 2]/@class
native returns 2 nodes
ajaxslt returns 1 node
Not sure about that first one, but there's a pretty clear explanation for
all those "//LI" tests. Haw-bin wrote:
----
I'm a little torn on this. It looks like one of the optimizations [Dan]
made back when we released AJAXSLT 0.8 is contrary to the XPath spec.
Specifically, in xpath.js LocationExpr.prototype._combineSteps , the
sequence of DESCENDANT_OR_SELF and CHILD is combined into DESCENDANT.
Unfortunately, the spec states explicitly that these are not equal:
NOTE: The location path //para[1] does not mean the same as the location
path /descendant::para[1]. The latter selects the first descendant para
element; the former selects all descendant para elements that are the first
para children of their parents.
This has us not passing muster on some of the llamalab benchmarks:
http://www.llamalab.com/js/xpath/benchmark.html [www.llamalab.com]
What I'm torn about is ... that removing the combining code re-introduces a
pretty big performance hit, at least for the special browser we all know
and love. On the other hand, these inconsistencies mean that relatively
simple XPaths that work in other browsers with native engines potentially
won't work in IE.
----
It took me a while to get my head around this... basically, [1] modifies
the context within the slash, but since //LI[1] is really
/descendant-or-self::node()/LI[1], it only modifies the part after the
second slash.
Original issue reported on code.google.com by [email protected]
on 16 Jun 2008 at 7:12
What steps will reproduce the problem?
See the file attached and open it with Firefox and IE. Click on "TestMe!".
What is the expected output? What do you see instead?
You should see "Result: 1" twice. That means that the XPath requests are
correctly executed. With IE the first request works but not the other one,
consequently you should see "Result: 1" and then "Result: 0"
What version of the product are you using? On what operating system?
v0.8.1
Original issue reported on code.google.com by [email protected]
on 21 Jul 2009 at 1:55
Attachments:
template like:
<xsl:template name="emptyOption">
<option value="">no value</option>
</xsl:template>
producies the floowing result:
<option>no value</option> instead of <option value="">no option</option>
Original issue reported on code.google.com by [email protected]
on 10 Sep 2008 at 10:49
What steps will reproduce the problem?
1. Create an HTML document that uses a link like this: <a
href="javascript:doFoo('a', 'b')">javascript href with spaces</a>
2. Attempt to match this expression with the xpath
//a[@href="javascript:doFoo('a', 'b')"]
What is the expected output? What do you see instead?
On FF2 & IE7, the expression matches. On IE6, the expression fails.
This is because on IE6, the browser returns the attribute value as
javascript:doFoo('a',%20'b'), for reasons that man may never understand.
This was SEL-347; it was fixed in a hack that worked around AJAXSLT that
didn't work for more complex XPath expressions. We should fix it in "real"
AJAXSLT as well and then get rid of the hack in Selenium.
http://jira.openqa.org/browse/SEL-347
Original issue reported on code.google.com by [email protected]
on 7 Nov 2007 at 3:01
Although the release notes of ajaxslt-0.4 states that 'xsl:sort' is fixed
in 'xsl:for-each' iterations, it seems to me that this still isn't fixed
completely. I have seen that a bug related to this issue was already
entered in the sf.net bugtracker, bug 1520401 - Sort is invalid, though
this bug report doesn't describe the issue properly but contains just a
post of xslt and xml instead.
I've looked at the ajaxslt source and located the issue. I found that
method "xsltProcessContext" calls the xsltSort on a sortContext without all
childnodes in its nodelist. Then method "xsltForEach" is called to do the
actual "xsl:for-each". It reads the nodelist from the context and uses it
without sorting it.
This issue can be fixed by retrieving the nodelist, then sorting it and
calling xsltForEach with the sorted context. The nodelist is always
retrieved from the "select" attribute within the "xsl:for-each" element, as
the select attribute is required with for-each iterations, while optional
for apply-templates.
A patch against xslt.js of release 0.4 is attached.
Original issue reported on code.google.com by [email protected]
on 11 Dec 2006 at 8:47
Attachments:
http://sourceforge.net/tracker/index.php?func=detail&aid=1375469&group_id=140999
&atid=748120
Original issue reported on code.google.com by [email protected]
on 15 Dec 2006 at 9:29
What steps will reproduce the problem?
1. Run this code:
<xsl:stylesheet>
<xsl:template match="/">
<xsl:variable name="header">
<tr>
<th>Element</th>
<th>Description</th>
</tr>
</xsl:variable>
<xsl:apply-templates select="page/message"/>
</xsl:template>
<xsl:template match="page/message">
<div>
<xsl:value-of select="."/>
</div>
</xsl:template>
</xsl:stylesheet>
using this XML:
<page>
<message>
Hello World.
</message>
</page>
What is the expected output? What do you see instead?
I expect that a local variable will be created in the root template. That
can be used later. The final output should be:
<div>
Hello World.
</div>
What I actually get is an error that crashes the javascript. When I view
the javascript console in FireFox this is what the error comes up as:
Error: input.node.ownerDocument has no properties
Source File: xslt.js
Line: 356
What version of the product are you using? On what operating system?
I am using version 0.5 on a PC.
Original issue reported on code.google.com by [email protected]
on 8 Dec 2006 at 7:49
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.