Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: SAX2 Lexical Handler Suggestions
 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="<cp:echo name=&qt;product&qt;>" 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@m...] 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@m... http://www.megginson.com/ 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
