xml-dev - sax-ext handlers (was: SAX2 Lexical Handler Suggestions)

[Eldar Musayev <eldarm@microsoft.com>]

If people need some odd events, which are 1% of cases, may be it is possible
to think about that as SAX properties and extensions? We already have
extension package sax-ext in SAX for Lexical and Declaration Handlers. Any
new stuff can go there and it will be up to implementors of SAX parsers,
which extensions to support based on their customer base needs. Of course,
such extensions must be strictly optional for the whole idea to be
acceptable. And this optional handlers should be also discussed, agreed upon
and somehow published, like it is done for Lexical and DeclHanders. Then
really useful extensions will become de facto standard just because of a lot
of people, using them.

For example, I thought that interface like:

interface ISAXAttributes {
	void attributeName(String QName, String LocalName, String RawName);
	void attributeValue(String Value);
} 

makes a lot of sense. Of course, it's not very good to implement in a parser
(SAX events producer) because of a namespace problem (you don't know
namespace until you finish parsing start tag). But for SAX events consumers
it makes a lot of sense. It allows users to generate attributes easily
without creating a SAXAtrributes object for every tag.

Just my 2 pennies to the discussion.

Eldar


-----Original Message-----
From: David Brownell [mailto:david-b@pacbell.net]
Sent: Wednesday, July 12, 2000 11:57 AM
Subject: Re: SAX2 Lexical Handler Suggestions

... and it's quite well known that editors require quite
a lot more than "Simple" functionality.  In fact they
usually demand all kinds of extra information which the
XML infoset explicitly discarded using the 80/20% rule.
(IMHO more lie 99/1 in this case.)

After seeing bits and pieces of editor requirements for
several years now, I think that if SAX is to support
that functionality it should be through specific APIs
(EditorHandler, maybe) addressing editor issues.  If your
itch involves having such features, I suggest you scratch
it in that way.  (I don't like how DOM cluttered up the
80% simple case with incomplate support for someone's 20%,
which btw is often labeled as "editor" stuff, and want to
see SAX stay uncluttered.)

It would need to expose at least part of a token level
event stream ... so that editors would not play with the
whitespace separating attributes (or outside of the root
element), rearrange attributes, change text encodings for
documents, and so on.

- Dave