On Sun, Apr 3, 2011 at 2:23 PM, Yitzchak Gale wrote:

After upgrading to xml-enumerator 0.2.1 and xml-types 0.2, I can no longer control the order of attributes in rendered XML.

The XML specification specifically allows this - you can change the order of attributes with affecting the semantics of the document. I need the attributes to be in a sane order for reading by humans so that the XML will pass my customer's acceptance testing.

What sort of order do they need to be in? If it's something like "alphabetical" or "sorted by length", then the serialiser should be able to handle it very easily. A completely custom ordering ("id first, then name, then location...") would be slightly harder, but not much. The only case I can think of where you'd need to store attribute ordering metadata in the attributes themselves is if you need them to be printed in exactly the order they were parsed. If you do need the ability to write attributes in exactly the order they're parsed, I'm willing to change to an association list, but I have concerns about performance (see below). If you just need them written in a dependable order, I think it would be better to handle that in xml-enumerator's serialiser.

Earlier versions of xml-types supported this, but 0.2 introduced an API change which forces attribute sets to be expressed as a Data.Map.

Why not just use association lists? That seems like a perfect fit. Or just go back to the old API.

I really don't want to go back to the old API. The 'Attribute' data type was annoying and unnecessary. On Sun, Apr 3, 2011 at 04:43, Michael Snoyman wrote:

For the record, I would like to see this change too. I'm less concerned about attribute ordering (just because I don't think any human ever reads my XML output... at least I hope for their sake they aren't), but it's a little more difficult to code against the current API than if we used an assoc list. I'm also not certain that we're gaining any performance by using Map, since there are rarely any significant numbers of attributes used that the difference between O(n) lookups for assoc lists and O(log n) for Maps will make a significant difference.

Some XML document formats use attributes extensively -- for these, the extra performance can matter. For example, if some element type supports 400 attributes, and a particular element of that type has 100, looking them up with an association list will be much slower than in a map.

OK, xml-types 0.3 has been published. It changes attributes to use an association list. Hackage should generate the docs momentarily.

John Millikin wrote:

OK, xml-types 0.3 has been published. It changes attributes to use an association list. Hackage should generate the docs momentarily.

Michael Snoyman wrote:

I'll upload a new release of xml-enumerator soon

Great, thanks much to both of you! Regards, Yitz