[jdom-interest] Internal DTD subset verification

[Philip Nelson]

--- Alex Rosen <arosen at silverstream.com> wrote:
> I don't think that the idea of a global switch is a good idea. It should be
> possible to have two different users of JDOM running in the same VM that
> each have their own verification policy. These might be two different
> editors in an IDE, or two different WARs in an EAR, or two different EARs on
> the same app server.

A classic example of a tradeoff.  This proposal doesn't make your scenarios any
better or any worse.  There is still the factory/field approach Brad just
submitted.  There is still subclassing. For Verifier, it seems like all of the
better ideas are off the table.  Using instance methods instead of static
methods would give us much more elegant and extendable ways to do verification
but at a cost in a part of the api that is the most performance sensitive.  I
also considered using reflection but again the cost is too high.

The real problem is that we are doing the verification in the wrong place.  I
almost hate to bring this up after the long and nasty discussion about allowing
an element to exist without a name, but if verification took place in the
outputters, with a required validator, we could have an interception point
where a programmer would have an opportunity to choose the appropriate
validator.  It would also be at a place where they need to write code anyway,
and would be much more convienient that having to do something like include a
validator instance in the constructor of Element, Attribute et al. It would
mean *gasp* that there exists the possibilty of a jdom document living in
memory that could not be produced as an xml document.

I bring this up because I want some alternatives to mindlessly spending cpu
cycles checking data but can see the value of garaunteeing well formedness.


__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com