Lists Home |
Date Index |
- From: David Megginson <email@example.com>
- To: xml-dev Mailing List <firstname.lastname@example.org>
- Date: Tue, 24 Feb 1998 14:10:03 -0500
Juergen Modre writes:
> > In an ideal world, we'd also have some kind of ability to ask to
> > parser to turn validation on or off, but I'm not certain that that's
> > practical: any thoughts?
> I thinks that is practical and necessary.
> One solution would be to have methods like:
> void setValidation(boolean validation)
> boolean getValidation()
> These methods can be called before starting to parse with
> the parse() method.
It's trickier than this -- for example, we'd probably have to create
an exception that is thrown if the underlying parser does not support
validation; furthermore, none of the parsers that I've looked at
supports a toggle like this, and we will be forcing another design
decision on them if we require this toggle.
> I also think a parse method with an systemId only as parameter would be
> convenient. (With targeting to users rather new to XML
> and not very used to the publicId's).
> public abstract void parse (String systemId)
> This would also avoid the need to call every time
> entityHandler.resolveEntity() to resolve the Entity.
It might be simpler, though I'm trying to keep the number of methods
to a minimum. It wouldn't affect EntityHandler.resolveEntity(),
though, since that does not exist solely for the sake of handling
Thanks, and all the best,
David Megginson email@example.com
Microstar Software Ltd. firstname.lastname@example.org
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)