And... I'm still going. I keep finding things that need addressing. I am in attributes now.
Anyway, I haven't gotten to the memory testing yet and I need to focus tomorrow on showing my client progress, so I'm sorry but this code will be another couple of days. If you do look into the as2 XMLDocument stuff and find issues with emulating that in Royale XML, feel free to ask me about anything that might be changing (to match what swf does). Otherwise it might be easier to wait and see if you really need some of those fixes. Once again, sorry for the delay. I prefer to get what I get in 'right' rather than have only some of it right. On Mon, Sep 9, 2019 at 5:33 PM Alex Harui <[email protected]> wrote: > No problem. I've spent today trying to fix the build in the Ant source > package. > > -Alex > > On 9/8/19, 10:03 PM, "Greg Dove" <[email protected]> wrote: > > Not quite there yet with the final changes, I'm afraid. I'm getting > close... should be tomorrow my time. > > > On Sun, Sep 8, 2019 at 7:32 AM Greg Dove <[email protected]> wrote: > > > > > Yeah thanks Josh, Alex made a suggestion for that option too, it was > the > > one I thought I would try first. I hope to get there later today, so > I will > > see if I can figure that out. > > > > > > On Sun, Sep 8, 2019 at 7:20 AM Josh Tynjala < > [email protected]> > > wrote: > > > >> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2F8ab1d813ee2f72bab957f9485e56ad89dcf6e1ab%2Fframeworks%2Fprojects%2FMXRoyale%2Fsrc%2Fmain%2Froyale%2Fmx%2Frpc%2Fhttp%2FAbstractOperation.as%23L1038&data=02%7C01%7Caharui%40adobe.com%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036021948216407&sdata=7V0k6g15%2FwI2JY7v7E32iLjX6lIUSkOs9%2BpRDfhOrGI%3D&reserved=0 > >> >> > >> >> > >> >> 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%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036021948216407&sdata=QYzb6f7nFoHlcmBuhWdsCW0PQY1JjEPAQAYZ%2FidI5Ys%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%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637036021948216407&sdata=X9r%2BkLD01gmHLU0sud1HN2IkHM8HZFLYFuIM5L%2FBDow%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%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637036021948216407&sdata=X9r%2BkLD01gmHLU0sud1HN2IkHM8HZFLYFuIM5L%2FBDow%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%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637036021948216407&sdata=X9r%2BkLD01gmHLU0sud1HN2IkHM8HZFLYFuIM5L%2FBDow%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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C2ddad385aee2449833fd08d734e2fe46%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637036021948216407&sdata=HJFY93gHQ4aSQP6%2BPL5ZlX4icGqdKngx7bLA1cTp9zI%3D&reserved=0 > > > >> > > > > >
