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

Would SAX event handlers be more cooperative?

• From: Michal Mosiewicz <mimo@i...>
• To: xml-dev@x...
• Date: Wed, 17 May 2000 01:22:45 +0200

I discussed it on apache-xml, but here seems to be a better place.

My question is if it would be nice, if SAX event handlers returned some
informations. Currently the events are only passed in a single
direction, i.e. a sax event producer passes them to content handler, but
it is not aware about how they are passed through the line of
transformations and serializers.

I would propose that ContentHandler.startTag() would return a value
indicating, if the contentHandler is "interested" in receiving the
following content of the tag. It would possibly return values like
CONTENT_OK and CONTENT_SKIP.

That would result, that a producer using this extended information would
look like this:

if( contentHandler.startTag(...) == CONTENT_OK ) {
    //contained events produced here
}
contentHandler.endTag()

Instead of:

contentHandler.startTag(..);
//contained events
contentHandler.endTag(...);

It has interesting implication. It allows for writing better optimised
application. For example - if due to some transformations, some
informations is never used from the source document, the producer
doesn't have to supply it possibly ommiting portions of the code that is
expensive to process. If the stylesheet is able to detect that some
element is not passed any further, it returns CONTENT_SKIP, so the
producer doesn't have to waste time for unnecessary transformations.

It also allows for building fine grained caching capabilities, like
saving preserialized content in the serializer, which is able to notify
all the producers along the line, that it uses this preserialized
content, so the content producer don't have to use any processor cycles
to provide it.

If the assumption is made, that these return values are taken more as
hints than a rule to follow, it could be probably implemented not to
interfere with existing code.

Comments?

-- Mike

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

• Prev by Date: thoughts on XInclude
• Next by Date: RE: Parse Error Not Thrown When Expected
• Previous by thread: thoughts on XInclude
• Next by thread: Anyone use Lore XML Database from Stanford ?
• Index(es):
  • Date
  • Thread