Thanks. Yeah I remember that is commented out. In a quick look, it wasn't
clear why XMLDocument was used instead of E4x in the WebService code. I will
probably just use e4x and see what happens.
-Alex
On 9/6/19, 5:30 PM, "Greg Dove" <greg.d...@gmail.com> 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%7Cb03f4d24bb5b4c3b297c08d7332a944b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637034130321301841&sdata=HKh9b5WI%2BFiclvbOKLNCFoVpj8cIh%2FUUHREeCef%2BNEU%3D&reserved=0
with '//old XML style'
On Sat, Sep 7, 2019 at 12:24 PM Alex Harui <aha...@adobe.com.invalid> 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" <greg.d...@gmail.com> 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 <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&data=02%7C01%7Caharui%40adobe.com%7Cb03f4d24bb5b4c3b297c08d7332a944b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637034130321301841&sdata=C0tyzSrA5FyKi0HOv72fMUgPhimhHby3F9%2BW0mfJMAU%3D&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&data=02%7C01%7Caharui%40adobe.com%7Cb03f4d24bb5b4c3b297c08d7332a944b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034130321301841&sdata=vW%2FufHSFv881ctf4rSTmmtr%2FFgYTGWUCRv%2F72WV%2F4XM%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%7Cb03f4d24bb5b4c3b297c08d7332a944b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034130321301841&sdata=vW%2FufHSFv881ctf4rSTmmtr%2FFgYTGWUCRv%2F72WV%2F4XM%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%7Cb03f4d24bb5b4c3b297c08d7332a944b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637034130321301841&sdata=vW%2FufHSFv881ctf4rSTmmtr%2FFgYTGWUCRv%2F72WV%2F4XM%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.
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
>
>
>
