I think we've agreed on the "design" part of grammar preparsing: a new interface XMLGrammarLoader is needed, and it has a bunch of set/get methods for features, properties, entity resolver and error handler, as well as a loadGrammar() method.
On the "implementation" front, I still have some points to express. But since they are implementation details, and we are still not sure how/whether the implementation would affect users, I don't feel too strong about them. 1. Where does loadGrammar(type, input) method live? I agree with Andy in that there are people who want to preload grammars into a cache, and having loadGrammar(type, input) method on an implementation of XMLGrammarPool would make things easier for them. But I see another kind of use of this method: preload a grammar, and access information about components in the grammar. Andy is right again: we don't have API to access such information. But this is changing: a schema component API is being prototyped, and will be available in a few months. (A detailed plan will be sent to the list soon, I think.) For this kind of users, they don't want to know anything about grammar pool/cache, and only wants an object that can load a given kind of grammar. This is why I think a util class with (only) this method is necessary. For the kind of requirements Andy mentioned, people can easily preload a grammar using this util class, then store it in a grammar pool implementation. 2. Initialize the object that has loadGrammar(type, input) method Currently Xerces supports 2 kinds of grammars: DTD and XML Schema, so people would expect to be able to load these two kinds of grammars using some object that has a loadGrammar(type, input) method (because, again, users shouldn't use classes in impl package directly). If such object doesn't live within a parser configuration (it won't if people just want to load a grammar and analyze it), then it doesn't have a chance to know loaders for DTD and schema. This is why I thought the constructor of such object can add loaders for these two kinds of grammars. Of course, the loadGrammar() method can do something smart too: if it fails to find a loader for the given "type", and the type is either DTD or schema, then it goes and gets the proper loader. I can easily live with this solution. 3. How validators load grammars Andy, from your message, I got the following impression. Correct me if I'm wrong. When the parser configuration creates various validators, it creates a bunch of grammar loaders accordingly, and stores them as different properties. Each validator will then query the proper property to get the grammar loader, and call loadGrammar(input) on it. The grammar loaders also implement XMLComponent interface, so that they'll be aware of any feature/property settings. I don't have any problem with this approach; just want to make sure this is what you intended. (We need some new internal property IDs.) Cheers, Sandy Gao Software Developer, IBM Canada (1-905) 413-3255 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
