XOM API for Processing XML with Java

["Bradley S. Huffman" <hip AT cs.okstate.edu>]

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