[web-devel] Cannot control order of XML attributes

[John Millikin]

> On Sun, Apr 3, 2011 at 2:23 PM, Yitzchak Gale <gale at sefer.org> 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 <michael at snoyman.com> 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.