[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SAX LexicalHandler::comment issue
- From: Rob Lugt <email@example.com>
- To: David Brownell <firstname.lastname@example.org>, email@example.com
- Date: Thu, 05 Jul 2001 21:33:05 +0100
David Brownell wrote:
> > What are other peoples thoughts? Is it worth proposing
> > startComment()/comment()/endComment() for SAX x.x?
> I tend to think not; what's the real win to changing that API?
> There's a measurable cost to changing APIs that are widely
> deployed ... I can't see an offsetting benefit.
I didn't mean to suggest that this issue alone deserves a new version of
SAX - I agree the benefit is too small. Rather, when sufficient pressure
for change occurs, this issue should be considered as part of any new
> I'd rather discourage folk from using comments in applications,
> actually ... :) So far as I know, the primary use case for reporting
> comments is to support DOM bells'n'whistles.
Comments are sometimes used to temporarily 'remove' large sections of a
document. I don't think you will ever be able to discourage this sort of
activity. Indeed it is this sort of activity that creates potentially very
large comments which may cause SAX processors a problem.
> There's a similar issue with reporting PIs ... the data passed to
> the target can be arbitrarily large. Any application that really
> cares about the content of comments should really be using PIs
> instead. (Text editors aside -- and those can't really be using
> "Application" programming interfaces.)
I don't see why comments should be treated any differently to any other XML
> On the other hand, I can't see worrying that names for elements,
> attributes, entities, and notations have no size limits, which is
> the other main place that SAX expects data to be string-ized.
In real life, element and attribute names are never likely to grow
outrageously large. Attribute values, on the other hand may do. However,
because attribute values are subject to normalization, a SAX processor has
no choice but to buffer the entire value.
Thanks for your input David. I had a feeling you would have something to
say about this;-)