|
Mike,
This is a logical explanation (and poor rationale) Interestingly I had this problem myself. Using a list was not an option because the attributes needed to be stored for fast lookup. I used a B-Tree rather than a Hash - and I took advantage of this "hole" in the spec myself by not-preserving attribute order until I had a client tell me they wanted the order preserved. I modified my B-tree so that it preserved insertion order just for this reason. Each node in my AVL- BTree, contains the normal [left] and [right] pointers but I added a [next] and [previous] just so that I could preserve the order. I can traverse that data structure in [Alphabetical, reverse alphebvetical, or insertion order]. Without that unusual customized data structure - created just for this problem the only solution would be to maintain two indexes (a list AND a hash) use the hash for random access and the list for iterating - but you must then keep both indexes updated. For example, delete or add to both the list and the hash. My "one of a kind" data structure is called GBTree (you will find it in the implementation source) - its handy because it accomplishes this without dual indexes. I agree this must have been the reason - to simplify the implementation. XML 2.0 should fix that if it doesn't break too much. Brian Date: Mon, 24 Mar 2014 22:49:26 -0400 From: msokolov@safaribooksonline.com To: xmlboss@live.com; simonstl@simonstl.com CC: xml-dev@lists.xml.org Subject: Re: [xml-dev] RFC for XML Object Parsing Consider a parser implementation that stores attributes using a hashmap. This will help guarantee uniqueness of the keys, which is needed, since two same-named attributes on a single element must be reported as an error. In general hashmaps do not preserve insertion order, so it may be that this was a rationale for discarding the order of attributes. I don't know. If so it wasn't a particularly good rationale. -Mike On 3/24/2014 10:26 PM, Brian Aberle
wrote:
|