Hi Henry, Hope you don't mind; I'm cc'ing xerces-j-dev since other developers might be interested in this discussion (and might well take a different view than me. :) )
First, thanks for the patches! I've looked them over and have a few comments for you to consider. First a general point: it really helps in reviewing patches if they can be submitted as diffs against current CVS code. If they don't come in this format, then we have to put them that way before committing them anyway; also, patching current CVS code helps to avoid conflicting with changes that have been made to the patched files since a release. In Xerces-land, we tend to like context diffs; so the -u option is preferred. "Henry Chan" <[EMAIL PROTECTED]> wrote: >In the meantime, I suggest that you temporarily remove >XMLGrammarBuilder.java Well... even if I agreed with your patch, it certainly doesn't address schema validation. And no question we need a sample demonstrating how that's to be done. >In short, what I found was that there wasn't really a concept of an >active Grammar to be used in the XMLDTDValidator (hence its value was >always null I don't think that's true. If you massage the XMLGrammarBuilder code a bit, you can convince it to physically remove an external subset that it's just parsed; if you do this, you'll find it happily validates files with appropriate DOCTYPEs. What's happening isn't that the concept of active grammar caching is missing, it's that use of the cached grammar is triggered by the presence of the DOCTYPE line, not by the appearance of the root element. So the fix would be to change this behaviour (while, natually, not breaking the default behaviour). >The DTDConfiguration file now takes in a setActiveGrammar method which >propagates an active Grammar to the XMLDTDValidator. >IMHO, I think it is the responsibility of the application to retrieve >the GrammarPool and set the Grammar to be used. If the whole GrammarPool >is to be used, it is up to the application to 'loop' with a foreach >Grammar in the Pool. The trouble is that it's not obvious how the application would know which grammar it wants to use for a given document *before* seeing that document. When we developed the grammar pool API, we thought applications would solve this problem by overriding the retrieveGrammar(...) method (i.e., either by providing their own XMLGrammarPool impl or by extending ours). Then the application is guaranteed to have all info the parser does, and can make an appropriate selection. So the approach in Xerces is quite general. So I'm afraid I don't think I can apply these patches. But this has helped refresh my memory of how this stuff is supposed to work, and hopefully you're a bit clearer on how we've set thing sup too. If you happen on any other ideas, I'd love to hear about them! Cheers, Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
