[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX LexicalHandler::comment issue

  • From: Rob Lugt <roblugt@e...>
  • To: David Brownell <david-b@p...>, xml-dev@l...
  • Date: Thu, 05 Jul 2001 21:33:05 +0100

sax xx
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/



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.