Skip to Content.
Sympa Menu

xom-interest - [XOM-interest] DocType.setInternalDTDSubset workarounds anyone?

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: xom-interest AT lists.ibiblio.org
  • Subject: [XOM-interest] DocType.setInternalDTDSubset workarounds anyone?
  • Date: Mon, 8 Nov 2004 12:08:38 -0800

Is there a known work-around for the fact that DocType.setInternalDTDSubset is not public?

The javadoc says:

The internal DTD subset is read-only.
* XOM fills it in when a document is read by a parser.
* However, it cannot be changed, because XOM cannot
* currently check that an internal DTD subset is well-formed.
* This restriction may be relaxed in a future version.

I need some way to create a DocType object with the same internal subset that I obtain with DocType.getInternalDTDSubset().

The use case is as follows: I'm reading all four strings of a DocType with getXYZ(), then write them to a file or database for persistent storage. Sometime later I need to reconstitute the very same DocType by reading those four strings from the file (or database), then constructing a new DocType and filling in the very same four string values. This is all part of a custom serialization/deserialization scheme.

Note that the usecase always fills in what it previously got from DocType.getInternalDTDSubset(), not some arbitrary other string. Hence there are no well-formedness issues here.

Also not that the ugly work-around involving parsing a fake string document with the embedded doctype is not viable: the parse will try to resolve references in the subset, an typically fail here.

I understand the reasoning for not making the method public, but perhaps it would be viable to make DocType.setInternalDTDSubset() protected, or make the internal private variable protected so custom subclasses can set it. My impression is that this would work fine, especially if there would be a note in the javadoc saying that one should only use this method if it is known that the supplied internal subset is conformant.

Finally note that Builder is a first-class citizen because it may use the package-protected setInternalDTDSubset, while everybody else is a second-class citizen, essentially precluding custom general-purpose serialization mechanisms to be expressed on top of XOM...

Thanks,
Wolfgang.





Archive powered by MHonArc 2.6.24.

Top of Page