Skip to Content.
Sympa Menu

xom-interest - Re: [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: "Bradley S. Huffman" <hip AT cs.okstate.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] DocType.setInternalDTDSubset workarounds anyone?
  • Date: Mon, 8 Nov 2004 13:58:31 -0800

That won't work as I need to build the new DocType in a different process, possibly remote, and typically at some time in the future. There is custom serialization in between: process A serializes a Doctype in a custom way, and some other process B later deserializes it.

Thanks anyway,
Wolfgang.

On Nov 8, 2004, at 1:52 PM, Bradley S. Huffman wrote:

DocType newDocType = new DocType(oldDocType);

Brad

Wolfgang Hoschek writes:

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.

_______________________________________________
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