xml-dev - Re: SAX2 Lexical Handler Suggestions

[Chris Pratt <chris@planetpratt.com>]

If it is inconceivable that someone would want to parse entity boundaries,
why are there startEntity() and endEntity() method in the LexicalHandler?
Obviously a number of people have found it useful to be notified when an
Entity boundary is encountered, true?  What is the harm in adding an extra
parameter to the callback that would identify whether the entity boundary
was located in element content or an attribute value?  Your assertion to
this point was that Entities are supposed to be completely transparent, but
if they're in the LexicalHandler, I guess being translucent mustn't be a bad
thing.
    (*Chris*)

----- Original Message -----
From: "David Megginson" <david@megginson.com>
To: "XML Developers List" <xml-dev@xml.org>
Sent: Wednesday, July 12, 2000 1:32 PM
Subject: Re: SAX2 Lexical Handler Suggestions


> Chris Pratt wrote:
>
> > So you're actually saying that XML can't handle this type of dynamic
> > processing???
>
> Not at all -- XML parsers do a fine job of handling entity references.
>
> What you want, however, is something quite different.  There is a lot of
> stuff in an XML document, and at one point, people had to sit down and
> decide what was signal and what was noise.  For many standard tools and
> specs the boundaries of entity references in attribute values (like
> whitespace within tags and a few other ugly details) landed on the noise
> side, so that XML APIs and specs could stay simple enough that people
> would actually implement and adopt them.
>
> It's entire possible to do what you want to do in XML, but doing it the
> way you're doing it rules out many existing software tools.  As a
> general rule-of-thumb, it's best to assume that anything except
> elements, attributes, text, and processing instructions will get chewed
> up and digested at parse time (most tools and specs go beyond this list,
> but not all in the same ways).
>
> You might want to take a close look at XSL, which can also be used for
> the kind of dynamic processing you're talking about (you can basically
> write an XHTML document with a few funny template elements and be
> XSL-conformant), but it does so while sticking strictly to the simple
> XML building blocks.
>
> > That seems very short sighted of the W3C.  I was able to make
> > SAX2 support this with minimal effort using small modifications to Dave
> > Brownell's AElfred2 parser, that would not make anyone's life more
> > difficult.
>
> If applications start to depend on this information, then either (a)
> everyone has to support it, or (b) we end up with a lack of
> interoperability.  Anyone can modify a single app or spec to add
> something like this, but the level of effort (or damage) becomes
> exponential when you look at the wider world.  Besides, it's not just
> *your* extension at stake -- other people will care just as strongly
> about different features, and in the end, all XML-based tools and specs
> will become CORBA-like (bloated, unusable, mutually-incompatible, and
> nearly impossible for a sane person to understand).  Granted, some
> people say we're already there, but at least we can try not to make
> things even worse.
>
> > I thought that this was an area for discussion of the uses of
> > this technology, but I guess I was wrong.
>
> Sure it is -- feel free to keep talking.  It's also a good place to hear
> opinions from others in the field, and sometimes they won't be the same
> as yours.
>
>
> All the best,
>
>
> David
>
> --
> David Megginson                 david@megginson.com
>            http://www.megginson.com/
>