xml-dev - RE: SAX2 Lexical Handler Suggestions

[Marc.McDonald@Design-Intelligence.com]

The problem with using an XSL solution is that XML does not allow elements
in an attribute, i.e. <input ... name="product" value="<cp:echo
name=&qt;product&qt;>" .../>

Independent of that is the problem of any application that serves as an XML
filter (which includes XML editors). Entity references need to be preserved.
If an editor read in an attribute name="&lt;cp:echo
name=&qt;product&qt;&gt;" it better not write it out as <cp:echo
name="product"> since the next XML parser that gets it will flag it as in
error.

Marc B. McDonald 
Principal Software Scientist
Design Intelligence Inc
(www.design-intelligence.com)

-----Original Message-----
From: David Megginson [mailto:david@megginson.com]
Sent: Wednesday, July 12, 2000 1:33 PM
To: XML Developers List
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/