SAX: org.xml.sax.AttributeMap

David Megginson ak117 at freenet.carleton.ca
Wed Feb 25 01:28:02 GMT 1998


We may as well take up the most difficult interface next, to get it
over with.  Here's what we have right now for attributes, which are by
far the most vexed problem in SAX:

  package org.xml.sax;

  import java.util.Enumeration;

  public interface AttributeMap {

    public Enumeration getAttributeNames ();
    public String getValue (String attributeName);

    public boolean isEntity (String attributeName);
    public boolean isNotation (String attributeName);
    public boolean isId (String attributeName);
    public boolean isIdref (String attributeName);

    public String getEntityPublicID (String attributeName);
    public String getEntitySystemID (String attributeName);
    public String getNotationName (String attributeName);
    public String getNotationPublicID (String attributeName);
    public String getNotationSystemID (String attributeName);

  }

BOY, DO I WANT TO CHANGE THIS ONE.  James has made some good
suggestions about how to make this simpler and more efficient by
working from list indexes (it also avoids the need to allocate an
Enumeration).  Here's what I want to change:

1. Rename the interface to org.xml.sax.AttributeList to reflect the
   new approach.

2. Add a method to return the length of the list.

3. Look up attribute information based on integer indices rather than
   string values.

4. Eliminate the is*() methods, and add a single method to return the
   attribute's type as a string instead.

5. Rename getNotationName() to getEntityNotationName() to make its
   role clearer.

With these changes, we end up with the following, somewhat simpler
interface:

  package org.xml.sax;

  public interface AttributeList {

    public abstract int getLength ();
    public abstract int getName (int index);
    public abstract int getValue (int index);
    public abstract String getType (int index);

    public abstract String getEntityNotationName (int index);
    public abstract String getEntityPublicId (int index);
    public abstract String getEntitySystemId (int index);
    public abstract String getNotationPublicId (int index);
    public abstract String getNotationSystemId (int index);

  }

The first four methods are actually very nice now (thanks, James, for
the suggestion).  As specified in the XML REC, getType() will return
"CDATA" if there is no explicit declaration, and it will return the
declared attribute type otherwise.  There's also no further dependency
on the Java-specific Enumeration class, so C++ programmers can sigh a
sigh of relief.

The last five methods are much more of a problem, and I'm still
agonizing over what to do.  Why do we have binary entities in XML at
all?  Is anyone going to use them, or will everything be done with
href's?

Attributes are the _only_ way to get at binary entities in XML, so if
I don't provide some way to get access to them here, then SAX parsers
and applications make it impossible to use binary (NDATA) entities at
all.  I am very reluctant to create a new class or interface just for
entities (and yet another for notations), when other types of objects
do not have their own classes, and I certainly don't want to re-invent
(or pre-invent) the DOM.  


HELP!!!


David

-- 
David Megginson                 ak117 at freenet.carleton.ca
Microstar Software Ltd.         dmeggins at microstar.com
      http://home.sprynet.com/sprynet/dmeggins/

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




More information about the Xml-dev mailing list