[jdom-interest] XMLOutputter/SAXBuilder

[philip.nelson at omniresources.com]

> I missed part of this thread, but I do see something that 
> needs addressing here. This proposal is orthogonal to what I 
> was asking for. 

Yes, sort of...

> 
> If we want to provide an isSpecified() method on Attribute 
> then this would be separate from the getType() method. 

I guess I have been thinking of this in terms of DocType providing the
answer rather than Attribute.  This eliminates the need for extra, often
dead references to an attribute type.

AttributeType type = aDoctype.getType(anAttribute);

In this case the programer could determine if the attribute *could* have
been produced from a default in the dtd.  That would have been enough to
help the programmer who started this thread, though it would have still
required a XMLFilter or SAXHandler subclass to get it done.  The DeclHandler
and subsequent reporting of attributes in the document will not give us
enough to say if a particular attribute came from the dtd or not. 

> 
> > I think
> >it would be possible when setExpandEntities is false and the 
> DTDHandler is
> >active.  Elliottes idea was some sort of AttributeType class 
> 
> You'd actually need a DeclHandler and then some to report 
> whether an attribute is or is not defaulted. I don't think 
> SAX2 exposes this in any consistent way. This is scheduled 
> top be added in SAX 2.1. However, attribute types are 
> available for all reported attributes in standard SAX.  

I glossed over this because the real point is this.  We chose (and I
implemented) an api where the internal subset is exposed as a string.  To
support some sort of getType method we have to instead model the dtd.  There
may be good reasons to do this, including supporting SAXOutputter. At the
time we made this choice, it was because even with the completely broken
entity api and no access to the dtd whatsoever, we got very few comments
about it.  

If it is a good idea, we need somebody to code it.  The points about dtd vs
schema had to do with another idea I have been basing assumptions on.  I
think the dtd should be modeled as xml in the doctype, or more specifically
as jdom elements and attributes.  This is how schema would be modeled I
assume, since it's already xml.  In both cases, modeling constraints would
require classes and an api.  Though I have worked my way through a few
schemas by now, I do not know the spec well enough to say if there is enough
in schema in common with dtd to try and model them the same way.  If
everything in a dtd could be modeled as a schema, well enough to turn around
and write the internal subset again, sharing a model makes sense, but I have
to think this is unlikely.  If I am right, the schema effort is separate
from the dtd effort and who will want it badly enough to do it?  Granted,
since the handlers have already been implemented, it won't be that hard.