The time has come to think about how we are going to support
InfoSet augmentations in XNI. This issue was raised recently
because, as the new XML Schema validation code is written,
we are looking at the features that we are going to have to
support -- mainly, the post-Schema validation infoset (PSVI).
While I'm generally opposed to adding XML Schema specific
APIs to the XNI framework, this is not the only case where
additional information will need to be communicated through
the document pipeline. So I would like to design a generic
solution on top of which an implementation dependent way to
communicate PSVI items can be written.
My initial suggestion (in case you missed my earlier post
since it was a response to Lisa posting the current Schema
status), is to add an InfoSet parameter to each and every
callback in the XNI handlers. For example:
void characters(XMLString text, InfoSet infoset);
This has several pros and cons associated to it, of which
I'll list a few in a second. But first, let me just start
off by saying that this is ONLY AN IDEA that I am throwing
out there in order to start some design discussion on this
topic. I'm NOT saying that it has to be done this way,
merely that it could be done this way. Having said that,
let me enumerate a few pros and cons:
PRO: The associated infoset augmentations are carried
along through the pipeline with the event.
This is an important point because if we were to develop
a mechanism that was "out-of-band" of the document flow,
then it's very easy for these parallel pipelines to get
out of sync. Since an XNI-compliant parser is modular
and the individual pieces in the pipeline can be arranged
and re-arranged, any specific stage can't know what will
happen once information leaves that stage. What if a
stage further down the pipeline *adds* or *removes*
XNI events? (e.g. namespace binding adds start/endPrefix-
Mapping events) So the easiest way to keep the data and
the augmentations in sync is to pass them together.
PRO: The info in the InfoSet parameter is generic.
By making it generic, we *allow* for things like PSVI,
etc. to be implemented but *don't force* all XNI parsers
and parser configurations to handle any specific type of
augmentation. In addition, if the InfoSet parameter
defined a kind of map where the augmentations were
assigned keys, then new kinds of augmentations can be
used together without the need to change the interface
or requiring a specific kind of configuration.
CON: The associated infoset augmentations are carried
along through the pipeline with the event.
By passing an additional parameter in every callback,
we will incur the extra overhead of an extra push and
pop of this parameter on the call stack at each stage
in the pipeline. Regardless of this penalty, though,
my initial opinion is that we have to take this hit
in order to make infoset augmentations work within
the XNI framework.
Thoughts?
--
Andy Clark * IBM, TRL - Japan * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
