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%7Cde670f3380f94b8fd82708d7317915d3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637032268439916076&sdata=lY0hDgIEf68pv9fzW6NopGDv5cBdR2wfB49npPDcT7Y%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%7Cde670f3380f94b8fd82708d7317915d3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032268439916076&sdata=65p3lsTIh3r%2BUB86WbQ%2F75Fcj8WhIAr9SuWxSS5se8k%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%7Cde670f3380f94b8fd82708d7317915d3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032268439916076&sdata=65p3lsTIh3r%2BUB86WbQ%2F75Fcj8WhIAr9SuWxSS5se8k%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%7Cde670f3380f94b8fd82708d7317915d3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637032268439916076&sdata=65p3lsTIh3r%2BUB86WbQ%2F75Fcj8WhIAr9SuWxSS5se8k%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.
> >
> >
> >
>
>
>
