XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

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