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

SAX: Sorting out org.xml.sax.AttributeList

• From: David Megginson <ak117@f...>
• To: xml-dev Mailing List <xml-dev@i...>
• Date: Sat, 28 Feb 1998 07:27:24 -0500

I have been working very hard to keep the number of interfaces in SAX
to a minimum, but it looks like there will be no way to avoid adding a
couple of additional ones if SAX is going to support unparsed entities
(as, I think, it must).

James's suggestion of using indexed properties instead of a lookup-map
is a very good, light-weight one.  If attributes, entities, and
notations are all indexed, then they will share a certain amount of
common functionality which should be split out into its own
interface:

  package org.xml.sax;

  public interface NameList {
    public abstract int getLength ();
    public abstract int getIndex (String name);
    public abstract String getName (int index);
  }

This is very JavaBean-like, except that getName does not throw an
ArrayIndexOutOfBounds exception (it just returns null for an invalid
index, and getIndex() returns -1 for a name that is not present).

Next, attribute lists extend this interface to add value and type:

  package org.xml.sax;

  public interface AttributeList extends NameList {
    public abstract String getType (int index);
    public abstract String getValue (int index);
  }

For notations, we need external identifiers instead:

  package org.xml.sax;

  public interface NotationList extends NameList {
    public abstract String getSystemId (int index);
    public abstract String getPublicId (int index);
  }

Unparsed entities are identical to notations, but they also need the
name of the associate notation:

  package org.xml.sax;

  public interface UnparsedEntityList extends NotationList {
    public abstract String getNotationName (int index);
  }

>From a purist point-of-view, UnparsedEntityList and NotationList
should both extend a common ancestor, like ExternalObjectList, but I
am becoming very concerned at the number of interfaces multiplying
here.

The application will gain access to these lists through a DTD
callback in org.xml.sax.DocumentHandler:

  public void dtd (UnparsedEntityList entityList, 
                   NotationList notationList)
    throws java.lang.Exception;

Should this event always be fired, or should it be fired only if there
actually is a DTD?


How does this sound to everyone?  For me, there are pros and cons:

PROS
----

1) This arrangement is _much_ simpler to understand than the old
   org.xml.sax.AttributeMap.  Most users can deal only with
   AttributeList (which is now trivial), and they can ignore
   NotationList and UnparsedEntityList unless they need to use
   unparsed entities. 

2) It is possible to look up a notation or entity directly by name,
   even if the name appears in a CDATA entity or in character data
   content.


CONS
----

1) Too many interfaces.

2) Users will complain that the dtd() callback does not return other
   information, such as lists of declared elements.

3) It may turn out that XML implementors shun unparsed entities and
   notations in favour of HREF's and MIME types, in which case we will
   have added this complexity to SAX for nothing.


Thanks,


David

-- 
David Megginson                 ak117@f...
Microstar Software Ltd.         dmeggins@m...
      http://home.sprynet.com/sprynet/dmeggins/

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...)

• Prev by Date: Re: SAX: org.xml.sax.AttributeMap
• Previous by thread: ANN: XLogo - programming with XML Logo Turtle Graphics
• Index(es):
  • Date
  • Thread