Hi Andy, >I suggest this change for two reasons: 1) having methods to >identify the grammar type on *both* the grammar and grammar >description interfaces seems superfluous; and 2) I think >that it would be simpler in the end to keep the grammar >description information with the grammar.
>If a grammar doesn't keep a copy of its associated grammar >description then each grammar pool instance needs to have >all of the logic to determine if a requested grammar >description properly identifies a registered grammar. To be blunt though: different grammar pool implementations are likely to differ considerably in how they deem grammars to be identical. So most of this logic will inevitably have to live there. But I think this design is cleaner and, since the Grammar object can be constructed by the validator with the XMLGrammarDescription that it just offered to the GrammarPool, I don't think there's any efficiency loss. So if there's no objection I'll go ahead and make Andy/Neeraj's suggested changes tomorrow. (For the record though I'm still a bit uncomfortable with attaching a systemId, for example, indirectly to a grammar object, when that object might be composed of many files. But this is a minor point.) >> 3. It should encompass both XML Schemas and DTD's; >And more... Of course! >And we need to be able to allow a DTD grammar to >a) be used in the case where the document contains no DOCTYPE >line and I think it's important that, like pretty much all other aspects of our default implementation, our default grammar caching framework should be spec-compliant by default. So I'd be uncomfortable if we didn't have a feature to control this functionality. >b) override the grammar specified in the DOCTYPE declaration. Same point as above. Besides, we'll still have to parse the internal subset at least--so that we can put out the requisite events if for no other reason. To my mind, the only obvious way of figuring out whether two DTD's with the same root name are equivalent is to look at their internal subsets; thus the getInternalSubset method in XMLDTDDescription. So that's the only thing I think our default implementation should look at by default. Cheers, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
