Re: attribute ordering

[Michael Allman <ms...@allman.ms>]

On Tue, 27 Jul 2010, Greg Brown wrote:

>> Call me naive or maybe just a newb but I didn't know that the order in which attributes appear on an element in bxml mattered.  I mean, in XML
>>
>> <element attr1="d24" attr2="hahth"/>
>>
>> and
>>
>> <element attr2="hahth" attr1="d24"/>
>>
>> are the same when considering each document's infoset.
>
> That may be true, but in the DOM order has relevance. Attributes are 
> stored as a list, not a map. Pivot's org.apache.pivot.xml.Element class 
> provides both keyed and indexed access to attributes.

Huh?  What language/implementation of the DOM are you referencing?  I'm 
looking at Java's org.w3c.dom.Node, in which an element's attributes are 
represented by a org.w3c.dom.NamedNodeMap.  The documentation for the 
latter explicitly states that NamedNodeMap does not imply an ordering.

Anyway, a list is a map.  Or to put it another way, any collection can be 
represented by a list simply by enumerating the elements of that 
collection in some way.  That does not imply that that collection has some 
kind of innate or natural ordering.

>> Yet there are clearly cases where the order in which the attributes are 
>> written is key. The one I ran into a moment ago is pretty simple.  The 
>> following works
>>
>> <ListView listData="['One', 'Two', 'Three']" selectedIndex="0"/>
>>
>> while the following does not
>>
>> <ListView selectedIndex="0" listData="['One', 'Two', 'Three']"/>
>>
>> The latter throws an IndexOutOfBoundsException.  Thoughts?
>
> The first one works because the list data is set before the selected 
> index. The second one fails because the list is empty when the selected 
> index is set. If ordering did not matter, we'd have no way to know which 
> attribute to set first.

Exactly.  There is nothing in the StAX spec that states that Attributes 
are indexed by the order in which they are written.

Michael

Re: attribute ordering

[Greg Brown <gk...@mac.com>]

>> An element's child nodes are also accessible via Node#getChildNodes(), which returns an ordered list of children.
> 
> True, but attributes are not children of elements and are not returned in a call to getChildNodes().

That is interesting. It has been a while since I worked with DOM - since Attr extends Node, I assumed they would be. Thanks for the clarification.

> Attributes in StAX have a specific ordering applied, but the spec says nothing about what order that is.  An implementation could order the attributes in reverse to their appearance in the XML file and still be in full compliance.  An implementation need only provide some enumaration for indexed access.

You are correct. I had assumed that, since StAX is a streaming API, attributes would be processed and accessed in the order in which they are encountered. This appears to be the case in practice (both with the BEA implementation as well as the JDK's), but the spec does not guarantee it.

> I'm really not suggesting that attribute ordering is irrelevant to BXMLSerializer.  I'm just saying that XML doesn't provide attribute ordering.  It's just one of those limitations of XML as a serialization language.

I don't think it is necessarily an inherent limitation of the language - for example, org.apache.pivot.xml.Element preserves attribute order. But for whatever reason, the designers of StAX and DOM chose not to. Oh well.

Re: attribute ordering

[Michael Allman <ms...@allman.ms>]

On Tue, 3 Aug 2010, Greg Brown wrote:

>>> in the DOM order has relevance. Attributes are stored as a list, not a 
>>> map. Pivot's org.apache.pivot.xml.Element class provides both keyed 
>>> and indexed access to attributes.
>>
>> Huh?  What language/implementation of the DOM are you referencing? 
>> I'm looking at Java's org.w3c.dom.Node, in which an element's 
>> attributes are represented by a org.w3c.dom.NamedNodeMap.
>
> An element's child nodes are also accessible via Node#getChildNodes(), 
> which returns an ordered list of children.

True, but attributes are not children of elements and are not returned in 
a call to getChildNodes().

>> Anyway, a list is a map.  Or to put it another way, any collection can 
>> be represented by a list simply by enumerating the elements of that 
>> collection in some way.  That does not imply that that collection has 
>> some kind of innate or natural ordering.
>
> It depends on the implementation of the map. Some have an implicit 
> order, while others do not. For example, the JDK supports a SortedMap 
> interface that imposes a strict ordering on key enumeration. A Pivot map 
> can be ordered by setting the comparator property.
>
>> There is nothing in the StAX spec that states that Attributes are 
>> indexed by the order in which they are written.
>
> Actually, there is. XMLStreamReader#getAttributeCount() returns the 
> number of attributes associated with the current element, and the 
> following methods return information about an attribute at a given 
> index:
>
> getAttributeLocalName(int index)
> getAttributeName(int index)
> getAttributeNamespace(int index)
> getAttributePrefix(int index)
> getAttributeType(int index)
> getAttributeValue(int index)
>
> Thus, attributes in StAX have a specific ordering applied. 
> BXMLSerializer takes advantage of this feature to ensure that attributes 
> are processed in the correct order. Regardless, you can later access the 
> properties in an unordered way if the deserialized element is a 
> Dictionary or a bean that can be wrapped in a BeanAdapter.

Attributes in StAX have a specific ordering applied, but the spec says 
nothing about what order that is.  An implementation could order the 
attributes in reverse to their appearance in the XML file and still be in 
full compliance.  An implementation need only provide some enumaration for 
indexed access.

> I'll ask you again to try to be a bit less aggressive and 
> arrogant-sounding with your posts. I have already explained why 
> attribute ordering is relevant in BXMLSerializer. I'm really not 
> interested in continuing to argue with you about it.

You are right---I came on pretty strong here and will tone it down.  I'm 
really not suggesting that attribute ordering is irrelevant to 
BXMLSerializer.  I'm just saying that XML doesn't provide attribute 
ordering.  It's just one of those limitations of XML as a serialization 
language.

Cheers,

Michael

Re: attribute ordering

[Greg Brown <gk...@mac.com>]

>> in the DOM order has relevance. Attributes are stored as a list, not a map. Pivot's org.apache.pivot.xml.Element class provides both keyed and indexed access to attributes.
> 
> Huh?  What language/implementation of the DOM are you referencing?  I'm looking at Java's org.w3c.dom.Node, in which an element's attributes are represented by a org.w3c.dom.NamedNodeMap.

An element's child nodes are also accessible via Node#getChildNodes(), which returns an ordered list of children.

> Anyway, a list is a map.  Or to put it another way, any collection can be represented by a list simply by enumerating the elements of that collection in some way.  That does not imply that that collection has some kind of innate or natural ordering.

It depends on the implementation of the map. Some have an implicit order, while others do not. For example, the JDK supports a SortedMap interface that imposes a strict ordering on key enumeration. A Pivot map can be ordered by setting the comparator property.

> There is nothing in the StAX spec that states that Attributes are indexed by the order in which they are written.

Actually, there is. XMLStreamReader#getAttributeCount() returns the number of attributes associated with the current element, and the following methods return information about an attribute at a given index:

getAttributeLocalName(int index) 
getAttributeName(int index) 
getAttributeNamespace(int index) 
getAttributePrefix(int index) 
getAttributeType(int index) 
getAttributeValue(int index) 

Thus, attributes in StAX have a specific ordering applied. BXMLSerializer takes advantage of this feature to ensure that attributes are processed in the correct order. Regardless, you can later access the properties in an unordered way if the deserialized element is a Dictionary or a bean that can be wrapped in a BeanAdapter.

I'll ask you again to try to be a bit less aggressive and arrogant-sounding with your posts. I have already explained why attribute ordering is relevant in BXMLSerializer. I'm really not interested in continuing to argue with you about it.

Re: attribute ordering

[Michael Allman <ms...@allman.ms>]

On Tue, 3 Aug 2010, Noel Grandin wrote:

> Michael Allman wrote:
>> On Tue, 27 Jul 2010, Greg Brown wrote:
>>
>>>> Call me naive or maybe just a newb but I didn't know that the order in which attributes appear on an element in bxml
>>>> mattered.  I mean, in XML
>>>>
>>>> <element attr1="d24" attr2="hahth"/>
>>>>
>>>> and
>>>>
>>>> <element attr2="hahth" attr1="d24"/>
>>>>
>>>> are the same when considering each document's infoset.
>>>
>>> That may be true, but in the DOM order has relevance. Attributes are stored as a list, not a map. Pivot's
>>> org.apache.pivot.xml.Element class provides both keyed and indexed access to attributes.
>>
>> Huh?  What language/implementation of the DOM are you referencing?  I'm looking at Java's org.w3c.dom.Node, in which
>> an element's attributes are represented by a org.w3c.dom.NamedNodeMap.  The documentation for the latter explicitly
>> states that NamedNodeMap does not imply an ordering.
>>
>> Anyway, a list is a map.  Or to put it another way, any collection can be represented by a list simply by enumerating
>> the elements of that collection in some way.  That does not imply that that collection has some kind of innate or
>> natural ordering.
>
> Michael is correct here:
> http://www.w3.org/TR/REC-xml/#sec-starttags
>
> Not sure that there is much we can do about it, unless we add some more 
> intelligence to the serialiser, so it knows what order to apply 
> attributes to beans.

Perhaps bean metadata?  I don't know.  You get into trouble when bean 
properties depend on each other.

Another way to think of the example I gave is that "selectedIndex" is not 
a proper writable bean property.  Rather than a noun, maybe it should be a 
verb, as in, public void selectIndex(int index)?  However, this would 
prevent its use as an attribute in bxml.

Another option would be to introduce an optional deserialization callback 
to override the default (bean) deserialization behavior.  In principal, 
this would work similarly to the readObject(ObjectInputStream) method from 
Java serialization, but would have a signature and behavior more suitable 
to bean serialization.  The callback would be declared on an interface, 
and the bean would have to implement that interface.

Another option would be to ignore this problem and accept the fact that 
attribute ordering is significant in bxml even through it's not in xml. 
Aside from deviating from users' understanding of xml, this option will 
require that users understand certain bean's property's dependencies and 
put them in the correct order in their bxml file.  Of course, this means 
bean properties may not have circular dependencies.  But then, if you're 
creating a JavaBean you should know better.

Michael

Re: attribute ordering

[Noel Grandin <no...@gmail.com>]

 Michael Allman wrote:
> On Tue, 27 Jul 2010, Greg Brown wrote:
>
>>> Call me naive or maybe just a newb but I didn't know that the order in which attributes appear on an element in bxml
>>> mattered.  I mean, in XML
>>>
>>> <element attr1="d24" attr2="hahth"/>
>>>
>>> and
>>>
>>> <element attr2="hahth" attr1="d24"/>
>>>
>>> are the same when considering each document's infoset.
>>
>> That may be true, but in the DOM order has relevance. Attributes are stored as a list, not a map. Pivot's
>> org.apache.pivot.xml.Element class provides both keyed and indexed access to attributes.
>
> Huh?  What language/implementation of the DOM are you referencing?  I'm looking at Java's org.w3c.dom.Node, in which
> an element's attributes are represented by a org.w3c.dom.NamedNodeMap.  The documentation for the latter explicitly
> states that NamedNodeMap does not imply an ordering.
>
> Anyway, a list is a map.  Or to put it another way, any collection can be represented by a list simply by enumerating
> the elements of that collection in some way.  That does not imply that that collection has some kind of innate or
> natural ordering.

Michael is correct here:
http://www.w3.org/TR/REC-xml/#sec-starttags

Not sure that there is much we can do about it, unless we add some more intelligence to the serialiser, so it knows what
order to apply attributes to beans.

-- Noel

Re: attribute ordering

[Greg Brown <gk...@mac.com>]

> I would actually consider an exception thrown because of attribute ordering
> to be a bug prior to getRoot or readObject in the serializer.

It's not a bug. It is by design. BXML is processed like a script, and order of execution is relevant. If you need different behavior, then BXML may not be the right tool for your use case.

> This does seem to motivate a good init protocol across the tree prior to
> returning from getRoot and readObject.

We have a good init protocol. The Bindable interface is used for this.

RE: attribute ordering

[aappddeevv <aa...@verizon.net>]

I would actually consider an exception thrown because of attribute ordering
to be a bug prior to getRoot or readObject in the serializer. I ran into the
same issue on some component's I authored but I realized I had to be robust.

Even in the DI containers such as spring, you have to be robust despite
attribute ordering specification issues.

This does seem to motivate a good init protocol across the tree prior to
returning from getRoot and readObject.


-----Original Message-----
From: Michael Allman [mailto:msa@allman.ms] 
Sent: Tuesday, August 03, 2010 2:22 AM
To: dev@pivot.apache.org
Subject: Re: attribute ordering

On Tue, 27 Jul 2010, Greg Brown wrote:

>> Call me naive or maybe just a newb but I didn't know that the order in
which attributes appear on an element in bxml mattered.  I mean, in XML
>>
>> <element attr1="d24" attr2="hahth"/>
>>
>> and
>>
>> <element attr2="hahth" attr1="d24"/>
>>
>> are the same when considering each document's infoset.
>
> That may be true, but in the DOM order has relevance. Attributes are 
> stored as a list, not a map. Pivot's org.apache.pivot.xml.Element class 
> provides both keyed and indexed access to attributes.

Huh?  What language/implementation of the DOM are you referencing?  I'm 
looking at Java's org.w3c.dom.Node, in which an element's attributes are 
represented by a org.w3c.dom.NamedNodeMap.  The documentation for the 
latter explicitly states that NamedNodeMap does not imply an ordering.

Anyway, a list is a map.  Or to put it another way, any collection can be 
represented by a list simply by enumerating the elements of that 
collection in some way.  That does not imply that that collection has some 
kind of innate or natural ordering.

>> Yet there are clearly cases where the order in which the attributes are 
>> written is key. The one I ran into a moment ago is pretty simple.  The 
>> following works
>>
>> <ListView listData="['One', 'Two', 'Three']" selectedIndex="0"/>
>>
>> while the following does not
>>
>> <ListView selectedIndex="0" listData="['One', 'Two', 'Three']"/>
>>
>> The latter throws an IndexOutOfBoundsException.  Thoughts?
>
> The first one works because the list data is set before the selected 
> index. The second one fails because the list is empty when the selected 
> index is set. If ordering did not matter, we'd have no way to know which 
> attribute to set first.

Exactly.  There is nothing in the StAX spec that states that Attributes 
are indexed by the order in which they are written.

Michael