SAX2: DTDDeclHandler (minimalist position)

[David Brownell]

David Megginson wrote:
> 
> 	 I'm still shying away from reporting element-type
> declarations, at least until someone shows me an easy and concise way
> of doing it (in AElfred, I simply provided the content model as a
> fully-normalised string).

That's what I'd prefer to see, and I really think that this interface
should provide element type declarations!

	public void elementDecl (String name, String model)
		throws SAXException;

Where "fully normalized" means spaces stripped, and PEs expanded.
If there are interned constants for the strings "EMPTY" and "ANY",
then it's fast to check for those; if the second character of
the string is '#' it's mixed content, else it's "children".

Also, for the record, I think that the DTD related methods you've
currently put into the lexical handler should be here instead.
Stuff like startDtd/endDtd, exposing the (optional) unnamed PE,
exposing the internal subset (unparsed).

(Separate comments on the "modified" handler you posted later.)

- dave


> ====================8<====================8<====================
> // DTDDeclHandler.java -- receive extended DTD declarations
> 
> package org.xml.sax;
> 
> public interface DTDDeclHandler
> {
>     public final static int ATTRIBUTE_DEFAULTED = 1;

This can be implied by a non-null value for "defaultValue".

>     public final static int ATTRIBUTE_IMPLIED = 2;
>     public final static int ATTRIBUTE_REQUIRED = 3;
>     public final static int ATTRIBUTE_FIXED = 4;

I'd prefer to see these be strings ... constant strings in
interfaces are all interned and can be compared as efficiently
as integers (use "==" or "!="), but are simpler to use when
debugging and programming.  "#IMPLIED" etc. and if you write
a constant "#IMPLIED" in your code, it's interned to the
very same string value.

There's a consistency point too:  why have integers for
these, and strings for the "type" (NMTOKEN, "ENUMERATION",
and so on)??

There was the comment about using these values in switch
statements ... except for large switches, they often get
compiled into if/else/else/fi blocks anyway, so for this
small a set of constants, I'm not sure there's a good
reason to avoid strings.


>     public abstract void attributeDecl (String element,
>                                         String name,
>                                         String type,
>                                         String defaultValue,
>                                         int defaultType,
>                                         EntityRefList entityRefs)
>         throws SAXException;

EntityRefList for holding enumerated values?

I've been thinking of this in terms of two callbacks, one for
non-enumerated values and the other for enumerated ones, and
just taking an array of strings (for entity names or the
enumeration options).  There really are two distinct sorts of
code path, and it's easier to branch early than to merge and
re-branch later.

>     public abstract void externalEntityDecl (String name,
>                                              boolean isParameterEntity,
>                                              String publicId,
>                                              String systemId)
>         throws SAXException;
> 
>     public abstract void internalEntityDecl (String name,
>                                              boolean isParameterEntity,
>                                              String value)
>         throws SAXException;

Exactly what Sun has (didn't we talk about this one once?) but
we don't expose parameter entities at all.

The good thing from exposing PEs:  possible to enforce the
namespace spec constraint that PE names have no colons.

The bad thing:  full PE handling gets really messy with stuff
like processing <!ATTLIST ... > declarations composed of multiple
PEs, inside default values, nested, etc.

I'd go for this API as it stands, but not expose PEs otherwise
since that's the "slippery slope".  Though I do like the idea
Lars posted, reporting PEs through a separate API.

> }
> 
> // end of DTDDeclHandler.java

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/ and on CD-ROM/ISBN 981-02-3594-1
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)