>> As long as you are willing to be parser specific you can do this.
>
>We are having a terminology gap here. I am not talking about your parser
>at all. I am talking about your validator. I want to plug your validator
>on top of some other SAX-compliant parser or SAX-smart XML event
>generator (e.g. Xalan). Of course the API to your validator is going to
>be specific to your validator (until there are validator API
>specifications) but I want the API between the XML event generator and
>the parser to be SAX. So I see no need to be parser specific.
>
But our validator is parser specific, i.e. there are no standards for these
kinds of interfaces, so using our validator means that whatever you do is
going to be somewhat Xerces-C specific. By 'parser' I really meant
'product' I guess, from your perspective. If you are willing to tie
yourself to non-standard APIs for such work, you can do what you want.
In the same way that I discussed for DOM revalidation, you can certainly
take the element and attriubte names you get via SAX and do the same things
with them. You look them up in the validator to get their ids, then call
the validator API to validate them. Or, if I can add the helper method,
you'd just build up a list of names and pass them to the helper method
which would look them up.
In terms of SAX, which are you are not interested in but for other people's
information, it would be optimal if it stored element ids itself. This
would allow maximum speed DOM revalidation. However, this does mean that
once you start programmatically modifying the DOM, extra effort would have
to be made to go back to the validator to try to find these new elements
and attributes and store their ids. But, when the DOM is being
programmatically modified, it might be that they never existed at all in
the DTD. The validator supports faulting these in with default definitions.
This will allow things to continue normally.
These ids will never match any content model of course, so they will always
be invalid unless the content model is updated. I don't even want to think
about what's going to happen when we want to start letting the DOM
programmatically update content models :-)
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
