I think the DITA files generated by asdoc are pretty big too, so they're probably really useful for your testing.
- Josh On Friday, September 6, 2019, Greg Dove <[email protected]> wrote: > '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. >>> >> > > > >>> >> > > > >>> >> > > > >>> >> > > >>> >> > > >>> >> > > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> >>> >> >>> >> >>> >>> >>> > -- -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev>
