[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: AttributeMap (was Re: Announcement: SAX 1998-01-12 Draft)

• From: "Matthew Gertner" <matthewg@p...>
• To: "James Clark" <jjc@j...>
• Date: Thu, 15 Jan 1998 10:37:57 +0100

James Clark wrote:


>If SAX is supposed to be abstract and extensible, then it needs a
>substantial rework.  Something like this would be much more extensible:
>
>interface DocumentHandler {
>  void startElement(StartElementEvent event);
>  void endElement(EndElementEvent event);
>  void characters(CharactersEvent event);
>  //...
>}
>
>Simplicity was the main design goal of SAX.
>
>Why do we get abstraction and extensibility for attributes but for
>nothing else?

Abstraction and extensibility are not absolutes. Although simplicity was the
main design goal, the need for good abstractions was clearly an ever-present
consideration. You yourself argued (quite rightly) for a separate
EntityManager interface, and the continuing discussion led to the definition
of several other separate interfaces. This is certainly a sacrifice of
simplicity for extensibility and very much correct, IMHO. In the case of the
AttributeMap, the lack of an elegant way to find an attribute by name is
pretty killer, even without considering the implications for extensibility.

>> Also, this makes iteration easy but
>> finding attributes by name very hard.
>>
>> An AttributeMap interface should be used, but:
>>
>> 1) It should provide a standard iterator interface (this is the only
>> reasonable way to iterate over a map).
>
>This has all the inefficiencies that I listed for Enumeration.
>Requiring an object to be allocated on each start-tag is really not a
>good idea (it makes a measurable difference to performance in Java).
>
>Something like this:
>
>interface AttributeList {
>  int length();            // or maybe size
>  String getValue(int i);  // or maybe valueAt
>  String getName(int i);   // or maybe nameAt
>  String get(String name);
>}
>
>would be significantly more efficient.
>
>At the very least provide an isEmpty() so that I don't have to do the
>allocation in the common case there are no attributes.

I didn't understand this. Why is an AttributeList interface inherently more
efficient than AttributeMap? The use of an AttributeMap interface doesn't
imply the creation of an object per start tag, any more than AttributeList
does. Are you assuming an underlying hashtable implementation (or whatever)?
This doesn't have to be the case; you could implement a map interface on top
of a list, which would be just as efficient as your "String get(String
name)". It seems to me that the metrics of the document and details of the
usage case (average number of attributes per tag, need to iterate
attributes, need to access attributes by name, etc.) would determine which
underlying implementation would be more efficient in which case. I also
don't see the need for "isEmpty()". Why not just instantiate a single "empty
map" object in the parser and send it whenever the attribute list is empty?

Matthew



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: AttributeMap (was Re: Announcement: SAX 1998-01-12 Draft)
    • From: James Clark <jjc@j...>

• Prev by Date: LISTRIVIA: Unnecessary traffic
• Next by Date: Documentation of DTDs
• Previous by thread: Re: AttributeMap (was Re: Announcement: SAX 1998-01-12 Draft)
• Next by thread: Re: AttributeMap (was Re: Announcement: SAX 1998-01-12 Draft)
• Index(es):
  • Date
  • Thread