Just to clarify.... I was referring to this stuff here: https://github.com/apache/royale-asjs/blob/8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab/frameworks/projects/MXRoyale/src/main/royale/mx/rpc/http/AbstractOperation.as#L1038
with '//old XML style' On Sat, Sep 7, 2019 at 12:24 PM Alex Harui <[email protected]> wrote: > I haven't looked at what XML is used/supported by MX HTTPService. It > looks like WebService does use MX HTTPService. I am currently migrating > other things that WebService needs (XMLEncoder/Decoder, > SOAPEncoder/Decoder). These are new files that aren't in the repo yet, so > HTTPService couldn't be relying on them or else their use is commented > out. The goal is to change as little as possible to get it to compile and > then see if it runs. I have no idea yet if the XML improvements you are > working on are going to be impactful on what I'm doing or not. > > BTW, I could be wrong, but I think that SWFDump will generate valid XML > and there is a way to get DITA files from Flex ASDoc that are valid XML. > > Thanks for the heads up, > -Alex > > On 9/6/19, 5:14 PM, "Greg Dove" <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected] > > > > 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" <[email protected]> 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 > <[email protected]> > >> 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" <[email protected]> > 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" <[email protected]> > 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 > >> <[email protected]> > >> > 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" < > [email protected]> > >> 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 > >> > <[email protected]> > >> > > 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&data=02%7C01%7Caharui%40adobe.com%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637034120784048005&sdata=hDhwbA6IQCFHQ3FQkNoVyaUcdZcxrzQS6ZWpiKrYr38%3D&reserved=0 > >> > > > > >> > > > 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&data=02%7C01%7Caharui%40adobe.com%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%3D&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&data=02%7C01%7Caharui%40adobe.com%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%3D&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&data=02%7C01%7Caharui%40adobe.com%7C329e3c957ece4fc05db908d733285bfb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034120784048005&sdata=obQ64fljxqdBKTzfY9RSLmZDOpC8Bphvex8ocpNBSwA%3D&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. > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > >> > > >> > > >> > >> > >> > > >
