Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XOM 1.1d1: setInternalDTDSubset

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: Wolfgang Hoschek <whoschek AT lbl.gov>
  • Cc: Elliotte Harold <elharo AT metalab.unc.edu>, xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] XOM 1.1d1: setInternalDTDSubset
  • Date: Sat, 8 Jan 2005 10:17:34 -0800

Plus you could move the "empty" static variable inside the method for improved clarity:

// private static InputSource empty;

static synchronized void checkInternalDTDSubset(String subset) {

if (parser == null) {
//empty = new InputSource(new EmptyReader());
final InputSource empty = new InputSource(new EmptyReader());
... and so on


On Jan 8, 2005, at 10:05 AM, Wolfgang Hoschek wrote:

Thanks. I'll try this when I can find some time. At first glance you could avoid any XMLReader cost for the common case (at least my common case) of an empty internal subset via:

public final void setInternalDTDSubset(String subset) {

//if (subset != null) { ...
if (subset != null && subset.length() > 0) { ...



On Jan 8, 2005, at 8:28 AM, Elliotte Harold wrote:

I don't know if I'm going to do a formal announcement or package a release or anything, but subscribers to this list may be interested to know that I've just checked some changes into CVS that allow an internal DTD subset to be specified as a string.

The publicly visible changes are the only addition of one method to the DocType class:

public void setInternalDTDSubset(String subset)

Behind the scenes, there's quite a bit more going on, some of which I know Wolfgang is going to hate because I've introduced another multithreading bottleneck in the Verifier class: a single static instance of XMLReader. However this should only affect the setInternalDTDSubset method. The alternative was to create a new XMLReader object for each call to setInternalDTDSubset, and that seemed way too heavyweight. I can't imagine that there'll be that many or frequent calls to setInternalDTDSubset, but if this actually proves to be a performance hit, then maybe I can explore using ThreadLocals instead.

I'm particularly curious to know if anyone can break the setInternalDTDSubset method. I foresee several possible failure modes:

1. Rejecting a well-formed subset
2. Accepting a malformed subset
3. Loading external entities

I've added a few unit tests for all this, but I may not have covered all bases, or anticipated every devious thing that could be done, If anyone spots a hole in my coverage, please holler.

-- Elliotte Rusty Harold elharo AT metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ ref=nosim

_______________________________________________
XOM-interest mailing list
XOM-interest AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/xom-interest

_______________________________________________
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