XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

What I needed was an alternative (high-performance) serialization 
mechanism. It serializes a document to some binary format and later 
deserializes from the binary format, yielding the *very same* document. 
So on deserialization I need a way to say setInternalDTDSubset(String 
subset) on an empty document, and pass in the same value I previously 
got on serialization from getInternalDTDSubset().  Just that; no fancy 
behaviour. The nodes of a document should not be altered in any way by 
setInternalDTDSubset, the only thing that should be altered is the 
subset string stored in the DocType. Until a better solution can be 
found, my workaround simply declares setInternalDTDSubset public.

Wolfgang.

On Jan 6, 2005, at 1:24 PM, Elliotte Harold wrote:

> There are two major issues on my list for XOM 1.1: XPath and internal 
> DTD subsets. They're a lot of other targets of opportunity, but these 
> are the two that I think are causing real pain by their absence. First 
> off: internal DTD subsets.
>
> The API for this is simple:
>
> public void setInternalDTDSubset(String subset)
>
> No muss. No fuss. The tricky part is implementation. I don't want to 
> write an entire DTD parser, and I'd like to avoid bundling yet another 
> 3rd part library. I had thought I could implement this simply by using 
> Builder, but someone (Wolfgang?) pointed out that this failed because 
> Builder always resolves external entity references. But we can work 
> around that. Rather than using a Builder, I'll just use a SAX parser 
> directly, and turn off external entity resolution.
>
> There are still some issues of concern, though:
>
> 1. The document might not be able to be read in again, if the entities 
> the internal DTD subset references are not found. I think we can live 
> with this, though it does bother me.
>
> 2. The internal DTD subset might declare default attribute values and 
> types which conflict with the attributes currently present or not 
> present on particular elements. This breaks round-tripping. However, 
> at least with respect to attribute type, round-tripping is imperfect 
> already.
>
> The alternative would be a much more complex API that has separate 
> methods like addAttributeDeclaration, addElementDeclaration, 
> addEntityDeclaration, etc. It would be more modular, and that might be 
> of use to somebody. I could probably do a syntax check of each target 
> individually, and perhaps apply default attribute values and adjust 
> types in the document as attribute declarations were added. But then 
> what happens when a document type declaration is detached? Honestly, 
> this is just too complex and I can't see it happening. I think the 
> worse is better, 80/20 solution is just to accept the internal DTD 
> subset as a string and ignore the round tripping issues.
>
>
> Thoughts?
>
>
> --
> Elliotte Rusty Harold  elharo AT metalab.unc.edu
> XML in a Nutshell 3rd Edition Just Published!
> http://www.cafeconleche.org/books/xian3/
> http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
>
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/xom-interest