Actually I know you are looking into the WSDL stuff.... maybe this is going
to be important for that (not sure)?
My goal is to get the XML stuff tidied up and ready to push by end of day
tomorrow, worst case the following morning, local time (UTC+12). I also
need to find some big XML test cases to check the memory side of things.
FYI there is also some XMLDocument stuff missing (commented out) from some
of the MX HttpService code, which came up in a recent issue. I don't know
if it shares any of the code from the WSDL stuff you are looking at or
not...
If it does then I don't want to double up on things, but otherwise I will
try to look at that on my Monday.



On Sat, Sep 7, 2019 at 12:02 PM Greg Dove <greg.d...@gmail.com> wrote:

> Thanks for checking that.
>
> child is specified in 13.4.4.6 and essentially calls [[Get]]
> (After cycling through this kind of thing a few times, I found the easiest
> way to find methods is to search in the spec for 'e.mehodName' which gets
> you XML.prototype.methodName)
>
> and [[Get]] is specified in 9.1.1.1
>
> So I assume it is a bug. As discussed I think it is good to match the
> behavior. If we can verify 100% it is off spec, we could add something as a
> define to avoid the 'fix' for people who want to be on-spec.
>
>
>
>
>
> On Sat, Sep 7, 2019 at 11:30 AM Alex Harui <aha...@adobe.com.invalid>
> wrote:
>
>> FWIW, I went and looked at the ABC.
>>
>> The first syntax sets up a getProperty just like any other property
>> fetch.  The second (as expected) calls "child()".  I've looked at the E4X
>> spec a couple of times now and cannot see where the behavior we are seeing
>> in child() is specified so I am going to assume it is a bug, and that we
>> just have to live with it.
>>
>> I expect that getProperty does not call child().  I haven't looked at the
>> AVM code to see what getProperty does for XML.
>>
>> HTH,
>> -Alex
>>
>> ´╗┐On 9/5/19, 12:05 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>>
>>     Oh that is a good find! And perfect timing :)
>>     Thanks Alex, I am pretty sure that answers the question! (It quite
>>     specifically describes what I was seeing, I don't think it makes a
>>     difference whether it is attributes or elements)
>>
>>     And yes, I agree it should be the implemented to give the same
>> results as
>>     swf.
>>     I will add this to the other work I have over the weekend before I
>> get it
>>     in. It only seems relevant for when child (or descendants, I don't
>> expect
>>     that will be different) method call is explicit (as opposed to the
>>     compiler-generated method calls from e4x 'member access') with QName
>>     argument only. I think most people won't use this approach with
>> explicit
>>     QNames, but it is one of those things that will cause misery if you do
>>     (when porting legacy code), so it should be the same IMO also. I will
>> make
>>     sure it costs nothing for the more common (other) use cases. I have
>> had to
>>     do something similar to support 'use namespace' directives which
>> create a
>>     MultiName-like variant of QName in my local change that includes the
>>     default namespace and the specified set of other 'used'/open
>> namespace uris
>>     in the current execution scope. (That 'use namespace' pattern was
>> being
>>     used quite a bit in the codebase I have been working on)
>>
>>     Thanks again, that will save me investigating it with bytecode.
>>
>>
>>
>>
>>     On Fri, Sep 6, 2019 at 6:37 AM Alex Harui <aha...@adobe.com.invalid>
>> wrote:
>>
>>     > Out of pure random chance, I was starting the migration of
>> WebService
>>     > which had a dependency on XMLUtil which contained the comment:
>>     >
>>     >         //xml.attribute(QName) will also return local no-namespace
>>     > attributes
>>     >         //even if we are looking for a specific full qualified name.
>>     >
>>     > So, still could be a bug in Flash, but maybe we should just make our
>>     > implementation work the same way to reduce migration effort in case
>> someone
>>     > is relying on this behavior.
>>     >
>>     > Thoughts?
>>     > -Alex
>>     >
>>     > On 9/4/19, 1:47 PM, "Alex Harui" <aha...@adobe.com.INVALID> wrote:
>>     >
>>     >     I read the example incorrectly.  So yeah, it should return 0
>> and empty
>>     > string in both cases, IMO.  There might be some subtlety in how the
>>     > namespaces are specified for a QName or how QName works in child().
>>     >
>>     >     HTH,
>>     >     -Alex
>>     >
>>     >     On 9/4/19, 11:33 AM, "Greg Dove" <greg.d...@gmail.com> wrote:
>>     >
>>     >         Good idea. I'll check the swf output, although probably
>> tomorrow
>>     > as I need
>>     >         to focus on something else today.
>>     >         ' I would have expected both to return "1" and the node.  '
>>     >
>>     >         In that example I would expect the opposite (because the
>> the link
>>     > node
>>     >         being returned by the second query is not in the specified
>> explicit
>>     >         namespace of the QName), so I am curious to understand why
>> you
>>     > think
>>     >         that... maybe it will help me understand.
>>     >
>>     >         When I use feed.atom::link I expect only links that are
>> bound to
>>     > the atom
>>     >         namespace (uri). Because <link ... /> node has no prefix
>> bound to
>>     > the uri
>>     >         that the atom namespace defines, and it is in the default
>>     > namespace, I
>>     >         would not expect it to be included.
>>     >         At the moment the atom::link part is working the same as
>> swf, so
>>     > I'm happy
>>     >         with that at least for what I am working on. All the
>> explicit
>>     > calls to
>>     >         child(name) or descendants(name) in the app I am working on
>> use
>>     > string args
>>     >         so these all work correctly as well.
>>     >         I'm just trying to cover things for the future... while my
>> head is
>>     > still in
>>     >         this stuff.
>>     >
>>     >
>>     >
>>     >         On Thu, Sep 5, 2019 at 6:11 AM Alex Harui
>> <aha...@adobe.com.invalid>
>>     > wrote:
>>     >
>>     >         > Speaking of multinames, what is the ABC code generated by
>> the
>>     > Flex
>>     >         > compiler for the two cases?  It might contain some
>> clues.  I
>>     > would have
>>     >         > expected both to return "1" and the node.  But I did see
>> in the
>>     > spec the
>>     >         > notion of "InScopeNamespaces".  I generally hate reading
>> specs
>>     > like these
>>     >         > so I am not very knowledgeable about what the spec says.
>>     >         >
>>     >         > HTH,
>>     >         > -Alex
>>     >         >
>>     >         > On 9/4/19, 11:05 AM, "Greg Dove" <greg.d...@gmail.com>
>> wrote:
>>     >         >
>>     >         >     'Have you rummaged through the spec?'
>>     >         >     Yes, if anything I probably need to step away from it
>> and
>>     > experience
>>     >         > the
>>     >         >     world a bit more! I have been focused on each portion
>> of the
>>     > spec as I
>>     >         >     create unit tests and verify things between the
>> player and
>>     > the Royale
>>     >         >     implementation.
>>     >         >     I've also glanced a few times in the avmplus code,
>> and that
>>     > has
>>     >         > provided
>>     >         >     some clues where things were intentionally implemented
>>     > slightly off
>>     >         > spec,
>>     >         >     but still a few things to figure out. However I am
>> making
>>     > progress - I
>>     >         >     think I have everything covered for the codebase I am
>>     > working on....
>>     >         > but I
>>     >         >     will keep going beyond that. For that example above,
>> I might
>>     > be wrong,
>>     >         > but
>>     >         >     I suspect it is using a multiname with default
>> namespace
>>     > included for
>>     >         > the
>>     >         >     explicit call case in the player, but not for the
>> implicit
>>     > one, but I
>>     >         > am
>>     >         >     not yet sure why. I will double-check the spec
>> though...
>>     >         >
>>     >         >
>>     >         >     On Thu, Sep 5, 2019 at 4:02 AM Alex Harui
>>     > <aha...@adobe.com.invalid>
>>     >         > wrote:
>>     >         >
>>     >         >     > Don't know.  Have you rummaged through the spec?
>>     >         >     >
>>     >         >     >
>>     >         >
>>     >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&amp;data=02%7C01%7Caharui%40adobe.com%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637033071564533291&amp;sdata=N1f5b20jjPP4SHWNM4hyleXMJW6qW%2FItnmgJ7oU73Hs%3D&amp;reserved=0
>>     >         >     >
>>     >         >     > HTH,
>>     >         >     > -Alex
>>     >         >     >
>>     >         >     > On 9/4/19, 3:11 AM, "Greg Dove" <
>> greg.d...@gmail.com>
>>     > 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%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637033071564533291&amp;sdata=l%2FaBdWHEKCOV%2ByL6NAaE6TFmOokIkA1nZNooLp0Ens0%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%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637033071564533291&amp;sdata=l%2FaBdWHEKCOV%2ByL6NAaE6TFmOokIkA1nZNooLp0Ens0%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%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637033071564533291&amp;sdata=l%2FaBdWHEKCOV%2ByL6NAaE6TFmOokIkA1nZNooLp0Ens0%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