Namespace issues.

[Shon Vella]

Just discovered FlexXB yesterday and really appreciate what you've done.

I have however noticed a few things related to namespaces that aren't quite what I would expect them to be.

1. It appears that deserialize completely ignores namespaces, e.g.

[XmlClass(uri="abc123")]

public class xxx {

}

will be instantiated when deserializing:

<xxx/>

or 

<x:xxx xmlns:x="abc123"/>

This is really bad when you need to deal with mixed vocabularies that come from different namespaces but have the overlapping local names.

2. In XML you can declare a default namespace (e.g. xmlns="abc123") that applies to all elements that do not have prefixes. But default namespaces never apply to attributes, so in order for an attribute to be in a namespace, it must always have a prefix. So given:

[XmlClass(uri="abc123")]

public class xxx {

   [XmlAttribute]

   var yyy:String = "abc";

}

I would expect serialization to produce:

<xxx xlmns="abc123" yyy="abc/>

which it appears to do, but if you actually look at the E4X objects underneath, the yyy attribute has a namespace uri but no prefix. It is unclear to me whether E4X is actually supposed to allow this but clearly the serialization process to a string would have to manufacture a prefix and associated namepace declaration in order to properly perform a toXMLString() operation and accurately represent the underlying XML infoset. So I think in this instance you have exposed a bug in the as3 implementation of E4X, either on the validation side or on the serialization side.

Further, it is much more common for an XML vocabulary to place elements but not attributes in a namespace, than it is to put attributes into the namespace as well, thus it would seem to make sense if the [XmlAttribute] annotation did not automatically inherit the namespace of the [XmlClass]. This would eliminate the need to add namespace="" to the vast majority of [XmlAttribute] annotations, and would be much more in keeping with the XML standard that requires a prefix for an attribute in a Namespace. It would also make it impossible to get the above situation where the attribute had a namespace uri but no prefix.

Anyway, I understand that addressing either of these issues is going to cause incompatibilities with current behavior, so if this actually gets fixed, I would suggest you have some flag that has to get set in order to enable the more correct behavior.

-Shon

[Alexutz]

Hi Shon,

 

Thanks for the appreciation. I'll see what I can do to solve this problems. Still, I must admit I did not fully understand the first problem. Can you please elaborate on it?

 

Thanks,

Alex