I haven't been following the schema changes in the parser, since I am not
interested in schemas at the current time. I would actually like to
prevent the use of schema validation (just use the DTDValidator). I
realize that some of the changes are generalizations to the validation
model, but I don't know much more than that.
If I understand what you are saying, there would be a series of callbacks
at some level to resolve entities. The order of the callbacks could be
configured. In my case, I would configure the parser so that it uses the
DTD grammar first and failing that, it would use my grammar which would
simply fail except in the case of non-character entities, in which case it
could replace the entity with whatever it wanted to. That would be wonderful.
Just looking briefly at the Grammar class, it would be hassle to implement
all of the pure virtual functions, so it would be helpful to have a do
nothing grammar that would act as a base class for the usage pattern I am
thinking of. I also don't really want to return an EntityDecl since I
wouldn't have one. I want to perform the substitution myself to avoid the
bookkeeping.
Chris
At 05:44 PM 6/7/2001, you wrote:
>Might be a little cleaner just to create a derived class of Grammar
>and to always respond to getEntityDecl (or a similar
>name) which gets called when the scanner encounters an non-character
>entity.
>
>The association of Grammar's with Documents will need to get
>rethought during the Schema push. So maybe during that
>time there will be the ability just to add your little
>grammer to the mix of schemas that the parser knows about.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
