Biju Reporter
	Description • 18 years ago

E4X: .. accessor and wildcard with attribute in filter

var a = <a i="0"><b i="1">
           <c i="2">element c2</c>
           <c i="3">element c3</c>
        </b></a>;

a..c.(@i=="2");     // gives "element c2"
a..*.@i;            // gives "123"
a..*.c.(@i=="2");   // gives "element c2"
a.b.*.(@i=="2");    // gives "element c2"
a..b.*.(@i=="2");   // gives "element c2"

// but
a..*.(@i=="2");     

// gives
// ReferenceError: reference to undefined XML name @i

step:-

1. navigate attachment "e4x_wildcard_attrib.html"
2. click Input Case "0" link
3. Click "test" button
4. repeat for links 1, 2, 3, 4 ....

	Biju Reporter
	Comment 2 • 18 years ago

E4X: .. accessor and wildcard with a node or attribute in filter

// also issue for nodes

var a = 
<a i="0"><b i="1">
  <c i="2">element c2<d>2</d></c>
  <c i="3">element c3<d>1</d></c>
</b></a>;


a..*.(d=="2");    
// give error
// ReferenceError: d is not defined


see e4x_wildcard_node.html

	Brendan Eich [:brendan]
	Comment 4 • 18 years ago

This bug is invalid per ECMA-357 Edition 2.  Given the value of the variable |a| shown in comment 2, we have:

js> L = a..*; for(i in L)print(typeof L[i], L[i].nodeKind(), L[i].toXMLString())
xml element <b i="1">
  <c i="2">
    element c2
    <d>2</d>
  </c>
  <c i="3">
    element c3
    <d>1</d>
  </c>
</b>
xml element <c i="2">
  element c2
  <d>2</d>
</c>
xml text element c2
xml element <d>2</d>
xml text 2
xml element <c i="3">
  element c3
  <d>1</d>
</c>
xml text element c3
xml element <d>1</d>
xml text 1

9 items in the list a..*, not all of them complex, not all having a child named |d|.  So a..*.(d) will give a reference error, just as eval("foopy") will if there is no such property named "foopy" on the scope chain.

ECMA-357 Edition 1 made all unbound XML names evaluate to undefined, which allows typos to pass undetected.  That seemed like a mistake.  To fix it, I proposed two possible solutions to ECMA TG1 over a year ago:

1.  Make all unbound references be errors.
2.  Throw a new exception, FilterReferenceError or some such, from within filtering predicate expressions, instead of ReferenceError.  Have the filtering predicate evaluator catch exceptions and, if the exception is FilterReferenceError silently continue to evaluate; otherwise rethrow.

TG1 went with door #1.  I believe the group now tends toward #2, but no one has implemented it that I know of.

/be

	Biju Reporter
	Comment 5 • 18 years ago

(In reply to comment #4)
> This bug is invalid per ECMA-357 Edition 2.  

I am agreeing now... E4X specification is stupid...

tested following and works fine.

var a = 
<a i="0"><b i="1">
  <c i="2">element c2</c>
  <c i="3">element c3</c>
</b></a>;


a..*.(function::nodeKind()=="element" && @i=="2"); 


But I think web developer's will be caught in this error unexpected, also make using "*" in e4x difficult to test any web application.

So I feel this bug should be changed to an ENHANCEMENT request.


Or I think there should be an ignoreFilterReferenceError flag in XML.settings
some thing like following works just fine.


var s = XML.settings();
s.ignoreFilterReferenceError = true;
XML.setSettings(s);

var a = 
<a i="0"><b i="1">
  <c i="2">element c2</c>
  <c i="3">element c3</c>
</b></a>;


a..*.(@i=="2"); 

	Brett Zamir
	Comment 6 • 16 years ago

I agree that it is very cumbersome throwing unavoidable errors or exceptions just because the item doesn't exist. It's not very helpful as a filter, if you always must have the item in question.

This occurs without wildcards as well:

var a = <a><b/><b foo="bar"/></a>;
alert(a.b.(@foo).toXMLString()); // "reference to undefined XML name @foo"

A workaround I found on the net (which I don't see documented in the spec, as with the "function::" notation) is:

alert(a.b.(function::attribute('foo')).toXMLString());  // Gives:
// <b/> 
// <b foo="bar"/>

So, can this be changed to an enhancement request?

(Also, while I'm at it, in case E4X bug reports can only go through formal channels, I think the attribute escaping in the spec should also be made to handle greater-than signs since they can be used with two left brackets to create the closing of a CDATA section, which creates invalid XML inside of an attribute; I'll file a separate bug if it should be filed at Bugzilla. Sorry to tack it on here, but I didn't know where else to post it.)

	Matthias Versen [:Matti]
	Comment 7 • 12 years ago

E4X will be removed again from Spidermonkey (bug 788293)