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: "Bradley S. Huffman" <hip AT cs.okstate.edu>
  • To: Wolfgang Hoschek <whoschek AT lbl.gov>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] DocType.setInternalDTDSubset workarounds anyone?
  • Date: Mon, 08 Nov 2004 15:52:49 -0600

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