Don't know.  Have you rummaged through the spec?
https://www.ecma-international.org/publications/files/ECMA-ST-WITHDRAWN/Ecma-357.pdf

HTH,
-Alex

On 9/4/19, 3:11 AM, "Greg Dove" <[email protected]> wrote:

    This is particularly for Harbs and Yishay, as I think you are both (or both
    have been) using XML quite a bit. I have quite a few  fixes coming. All
    with tests that match on swf and js.
    
    I am currently working to demonstrate proof of concept to a prospective
    client for migration of a Flex app. The app makes extensive use of e4x and
    uses a bunch of features that I expect had not received attention
    previously, because they were originally either not working with the
    codebase I am porting, or i think some even caused errors in the javascript
    output.
    
    So I have spent the last several days almost full time figuring things out
    and working on fixes, between the compiler and emulation classes.
    All the previous XML tests continue to pass, but I have many more unit
    tests and fixes lined up for the following:
    
    namespace directives
    default xml namespace
    use namespace (multiple)
    
    a number of fixes for xml filtering, including:
    -'this' resolves correctly in filters that include external references from
    the fitler expression to the 'this' scope
    -handles alternate ordering of comparisons between XML 'getters' and
    literals
    e.g. something.(name() = "cat")  or something.("cat" = name()) (these are
    the same)
    -it (will) now handle XML e4x references in nested function calls inside
    the filter, e.g. things like:
    e.g.
    var people:XML = <people>
                    <person>
                        <name>Bob</name>
                        <age>32</age>
                    </person>
                    <person>
                        <name>Joe</name>
                        <age>46</age>
                    </person>
                </people>;
     var findJoeByAge:Function = function (i:int):Boolean {
                    return i > 40;
                };
    people.person.(findJoeByAge(parseInt(age))).name
    
    
    I have lots more granular tests in QName, Namespace, and XML with tuning to
    improve reliability.
    toXMLString XML node output also matches flash more correctly in what I
    have coming.
    
    One thing that I am trying to figure out, which I would appreciate input on
    if someone has an answer:
    For the example:
    
    var feed:XML = new XML(
                        '<feed 
xmlns:atom="https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2005%2FAtom&amp;data=02%7C01%7Caharui%40adobe.com%7C4fc6b31478da4718992c08d7312038b5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637031886769375971&amp;sdata=YxDoQRD0NhfUfCK1QWIazLqeiP7vNRFFCaOLFF1NIow%3D&amp;reserved=0";
    xmlns:m="nothing">\n' +
                        '  <link rel="no_namespace"
    href="blah/12321/domain/"/>\n' +
                        '</feed>\n');
    var atomSpace:Namespace = new 
Namespace('https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2005%2FAtom&amp;data=02%7C01%7Caharui%40adobe.com%7C4fc6b31478da4718992c08d7312038b5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637031886769375971&amp;sdata=YxDoQRD0NhfUfCK1QWIazLqeiP7vNRFFCaOLFF1NIow%3D&amp;reserved=0');
    
    Can anyone explain why this (in SWF, as a reference implementation):
    trace(feed.atomSpace::link.length())
    trace(feed.atomSpace::link.toXMLString())
    //output:
    0
    {empty string}
    is different to:
    trace(feed.child(new QName(atomSpace,'link')).length())
    trace(feed.child(new QName(atomSpace,'link')).toXMLString())
    //output:
    1
    <link rel="no_namespace" href="blah/12321/domain/" xmlns:atom="
    
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2005%2FAtom&amp;data=02%7C01%7Caharui%40adobe.com%7C4fc6b31478da4718992c08d7312038b5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637031886769375971&amp;sdata=YxDoQRD0NhfUfCK1QWIazLqeiP7vNRFFCaOLFF1NIow%3D&amp;reserved=0";
 xmlns:m="nothing"/>
    
    I had assumed the above cases would be the same, but the second one is
    behaving as if it has the default namespace included with the specified
    namespace in the QName matching (it does correctly match the namespace
    specifically as well -with e.g. <atom:link nodes where the prefix atom is
    bound to the uri, but also seems to include link nodes with the default
    namespace, whether or not it is declared). I can accommodate this
    difference to make them behave the same, I just would like to understand
    the basis for the actual rules if anyone knows....
    
    I should be in a position to push the updates this coming weekend I think.
    

Reply via email to