OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] RFC for XML Object Parsing

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.


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.


On 3/24/2014 10:26 PM, Brian Aberle wrote:
This was the only email I didn't reply to today - for fear of an off-topic argument.  First of all I sincerely hope that this is not a 2 sided argument, its a discussion.  I thought that ALL SAX parsers preserved order, I learned today that some do not.  If the world was to increment the XML spec it would seem logical that attribute order would be preserved - but this must be a topic that has been exhausted already.  One SAX implementation can preserve order and another cannot - this is the state of the world at the moment.  I don't want to start an argument about a non-essential issue or carry this thread off-topic but I am curious myself if there was a reason for this, if it was an oversight, or if it was done to simplify the implementation.  Perhaps someone out there has the answer for the reasoning behind XML's attribute order discarding.
> Date: Mon, 24 Mar 2014 17:19:57 -0400
> From: simonstl@simonstl.com
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] RFC for XML Object Parsing
> On 03/24/2014 03:30 PM, Amelia A Lewis wrote:
> > On Mon, 24 Mar 2014 13:25:01 -0600, Brian Aberle wrote:
> >> Attribute order matters,oid must be first however, OID IS NEVER REQUIRED.
> >
> > You do realize that this means "this is not XML"?
> >
> > You can't even guarantee attribute order in SAX. Suggesting that
> > attribute order matters is pretty baffling, altogether.
> I can't help feeling that I'm taking the wrong side of the argument, but
> I've always thought that discarding attribute order was one of the
> unforced errors of the XML spec!
> Thanks,
> Simon
> _______________________________________________________________________
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS