Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XOM 1.1: Internal DTD Subsets

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] XOM 1.1: Internal DTD Subsets
  • Date: Thu, 6 Jan 2005 14:03:43 -0800

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





Archive powered by MHonArc 2.6.24.

Top of Page