[jdom-interest] Full Infoset support?

[Jason Hunter]

There may be aspects of the infoset that we don't want to implement. 
For example, iirc, infoset has the notion that the DocType is a node in
the document with a location in the tree.  JDOM has the more
common-sensical notion that the DocType is simply an attribute of the
Document and on output resides wherever it's placed, generally at the
beginning of the output stream.

I think infoset compatibility is desirable where possible, but full
compatibility may need to be sacrified for ease of use.  Maybe not. 
It'd be interesting to see the delta we have.  And it'd be good to
discuss what benefit "infoset compatible" provides.

-jh-

Elliotte Rusty Harold wrote:
> 
> About a year ago it was stated that a goal of JDOM was full infoset compatibility. i.e. every information item in the infoset should be exposed in a JDOM object tree somewhere. At the time we were thinking about namespaces, but it's relevant elsewhere as well.
> 
> Question: is this still a goal worth pursuing? If so, there are a number of areas where we're lacking and need some more work before 1.0. Specifically:
> 
> 1. The notations information item of the Document information item
> 2. The unparsed entities information item of the Document information item
> 3. The base URI of the document entity
> 4. The type of an attribute
> 5. The references of an attribute
> 6. Many other places...
> 
> I suspect most of these involve adding pieces to the API rather than changing what exists there now. Most work would be in the core and input packages, very little if any would be in the output package. The biggest downside is that we would be expanding memory usage by some percentage per object.
> 
> If we still want to aim for full infoset support, then I'll volunteer to do a read through off the infoset spec with an eye on what we still need to add to JDOM to support it. However, if we're no longer aiming for full infoset support, then there's not a lot of point to a detailed comparison.
> 
> Infoset support is important for a number of newer specs including XInclude. It's also being used in some other areas such as XSLT conformance testing at OASIS. Currently, only SAX really exposes almost everything in the infoset. DOM definitely leaves out pieces. It would be nice if JDOM could be added to SAX as a very infoset savvy API.
> --
> 
> +-----------------------+------------------------+-------------------+
> | Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
> +-----------------------+------------------------+-------------------+
> |          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
> |              http://www.ibiblio.org/xml/books/bible2/              |
> |   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
> +----------------------------------+---------------------------------+
> |  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
> |  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |
> +----------------------------------+---------------------------------+
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com