'I think that SWFDump will generate valid XML and there is a way to get DITA files from Flex ASDoc that are valid XML.' Sounds like a good idea for some large xml files. I did not use that yet, so will take a look and see if I can figure it out. Thanks!
On Sat, Sep 7, 2019 at 12:30 PM Greg Dove <[email protected]> wrote: > > 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. >> >> > > > >> >> > > > >> >> > > > >> >> > > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >> >> >> >> >> >> >>
