With the Schema Component Model API, users can access various properties of schema components. Then there comes the question: how to get an instance of XSModel from schema grammars.
One obvious approach is via PSVI: after an instance is validated, there will be a [schema information] property in the PSVI item of the validation root element. This property can have a method to return an *XSModel*, which contains all components corresponding to the [schema components] property in the PSVI. (3.15.5) But there are users who are interested in loading a schema grammar, then accessing the components, without validating an instance. So we need the ability to load schema grammars, and get *XSModel* from them. Before going into the options we have here, I'll first review 1) our grammar loading design; 2) XSModel and its future. 1. Grammar loading Basically there will be loader classes for different kinds of grammars. They have *loadGrammar* methods (or similar names), which return grammar objects (implementations/subclasses of *Grammar/XMLGrammar* in XNI). In the case of XML Schema, *loadGrammar* returns instances of SchemaGrammar. SchemaGrammar contains components from one target namespace, and has links to other schema grammars that it imports. This is what I'd like to call the "one-grammar-per-namespace" rule. Note that the schema spec doesn't require this, and other parser might choose other ways to store schema components. 2. XSModel XSModel models a "schema" defined in the schema spec, so it's a collection of components from a list of target namespaces. These namespaces might not be connected by importing. For example, in the instance document xsi:schemaLocation="ns1 xsd1 ns2 xsd2" After validation (if both ns1 and ns2 are referenced in the instance), the final schema/XSModel contains components from both namespaces. Various things could happen to XSModel in the future: 1) Some organization standardizes Schema CM API, which could be substantially different from our XSModel. Then we'll (have to) implement such standard API, and (quite possibly) drop XSModel, because supporting both APIs would confuse the users. 2) XSModel interfaces are adopted by some standard organization as the Schema CM API. Then these interface would be independent of Xerces. 3) Neither of the above happens, so XSModel becomes part of XNI, and lives there (forever). Now let's get back to our subject: how to get XSModel from loaded grammars. There could be 3 options: 1. XSModel extending Grammar Then our SchemaGrammar (implementation class) implements XSModel. After *loadGrammar* returns, the user can cast the returned Grammar to XSModel, and access the components. Pros: - The relation between Grammar/XSModel/SchemaGrammar is explicit, and the user can easily know how to cast one to another. Cons: - XSModel depends on an XNI interface. So if XSModel is adopted by some organization to become Xerces-independent, we need to come back and reconsider this problem again. - Because XSModel != (the current) SchemaGrammar, as discussed above, we need to alter the "one-grammar-per-namespace" rule a little bit. We'll need a flag in SchemaGrammar to indicate whether it's a container grammar (without a target namespace, containing other SchemaGrammar objects) or a real grammar (with a target namespace). - SchemaGrammar needs to carry the burden of implementing XSModel. But this may not affect the performance of validating instance documents. 2. No explicit relation between XSModel and Grammar interfaces SchemaGrammar implements both XSModel and Grammar. After *loadGrammar* returns, the user needs cast the returned Grammar to XSModel, and access the components. Pros: - XSModel doesn't depend on XNI. Cons: - Casting Grammar to XSModel might be *weird*, because there is connection between the two interfaces. (It's like cast a DocumentHandler object to a DeclHander object.) - Because XSModel != (the current) SchemaGrammar, as discussed above, we need to alter the "one-grammar-per-namespace" rule a little bit. We'll need a flag in SchemaGrammar to indicate whether it's a container grammar (without a target namespace, containing other SchemaGrammar objects) or a real grammar (with a target namespace). - SchemaGrammar needs to carry the burden of implementing XSModel. But this may not affect the performance of validating instance documents. 3. Construct an XSModel from SchemaGrammar objects XSModel doesn't depend on XNI. We'll have an XMLSchemaGrammar deriving from Grammar. A method *toXSModel* on such interface returns an XSModel that contains all components from this schema grammar; it could also have a overloaded *toXSModel* method that takes a list of XMLSchemaGrammar objects, and returns an XSModel. Pros: - XSModel doesn't depend on XNI. - XSModel and Grammar doesn't need to be connected - "one-grammar-per-namespace" rule doesn't need to be altered, because XSModel contains a list of XMLSchemaGrammar Cons: - More complicated design: one more interface in XNI - Whenever *toXSModel* is called, a new XSModel is created. This may or may not be a performance problem, depending on how XSModel is used. These are the options we could think of. What do folks think? Are there other solutions? 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]
