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

Re: filtering noise (was Re: SAX LexicalHandler::comment issue)

  • From: David Brownell <david-b@p...>
  • To: xml-dev@l...
  • Date: Fri, 06 Jul 2001 15:26:18 -0700

filtering noise
"> == Mike.Champion@S...

> But I've also been answering "help!" questions about the DOM long enough to
> know that you can't assume that anyone will RTFM (RTFS?), and setting the
> default to throw away noise will inevitably lead to howls from people who
> *need* their <expletive deleted> comments, PIs, and CDATA sections. 

I've been answering "help!" questions (in general; less recently for DOM :)
to know that howls come up regardless of whether or not you do the right
thing!  So for such issues I look at other factors:  which approach makes
better systems be easier to develop?  Which wastes less memory?  (That
can be be a real concern for DOM developers.  I've seen "noise" costs
in the 20% range for some data models, though they vary wildly.)

> I don't think the DOM can take the lead here; either the InfoSet has to
> first define the difference between music and noise, or the XML Core folks
> have to deprecate the noise from XML syntax, and then the DOM can follow.
> ...
> So, I guess my answer is just as cowardly as John Cowan's explanation of why
> the InfoSet still represents the noise :~)

Yep ... nobody willing to take a stance about policy, beyond "enable all of
them".  That's a symptom of organizations at certain points in their growth;
I've seen it (too) many times!  There are much worse process outcomes,
but I'll still prefer better ones.

> Seriously, folks ... to paraphrase Clemenceu and Gen. Jack D. Ripper, "XML
> is too important to be left to the experts."  The trouble with most people
> who work on these specs is not that they're stupid, but that they know too
> damn much about how this stuff works (and worked in SGML), how it really is
> useful under some circumstances, and how to ignore it when it's not useful.
> If y'all want simplicity, sanity, layering, modularity, etc. you're going to
> have to collectively put some feet to the fire, or maybe vote with your own
> feet.

I think there's a certain feeling that neither of those options seems to be
particularly viable with respect to W3C.  (Consider that upcoming workshop
addressing the fact that lots of XML-ish specs don't seem to layer cleanly.)

On the other hand, I did (re)submit feedback this morning to the DOM WG
that noisy data representations shouldn't be the default, which is as much as
most of us are in a position to do.

- Dave


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.
First Name
Last Name
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.