OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SAX LexicalHandler::comment issue



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
release.

> 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
information items.

> 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;-)

Regards
~Rob

--
Rob Lugt
ElCel Technology
http://www.elcel.com/