I wrote:
I think first you've got to confirm what you're representing--the complex type definition and _not_ the complex type itself.
Are you representing just the incremental information given in the complex type definition, or are you representing collected information about the complex type (the information given directly in the complex type definition plus information from the base type (and the base of the base type, etc.))?
I notice that for a group reference, JaxMeXS does not explicitly represent the use of the group but instead represents the effect of using the group.
That makes me think that maybe your intent was to represent the net collected information and not just the incremental information.
Applications like mine need incremental information, but (I assume) JaxMe needs collected information, and, although it could collect the information itself from a representation of the incremental information, the rest of JaxMe would prefer that JaxMeXS provide collected information.
(More specifically, my application needs to know about the _structure_ of the schema, for example, a chain of complex type _definitions_ that defines a complex type; I think that the rest of JaxMe wants to know about the net _results_ of the schema, for example, the net complex _type_ that is defined by that chain of complex type definitions.)
I think that JaxMeXS might be able to serve both purposes.
One potential solution is to add an additional layer.
Recall how you separated the syntax parser, whose Java objects represent the concrete, XML representation of an XML schema, from the logical parser, whose objects represent the abstract, logical meaning of an XML schema.
The potential solution would be to replace the logical parser layer with two layers: - a layer for incremental information, precisely representing what the XML Schema specification calls schema components and their properties (e.g., a complex type _definition_), and - a second layer for the net, resulting information (e.g., the complex _type_ that is defined by a complex type definition and everything that definition refers to).
Objects in the first layer would represent schema components (e.g., interface ...ComplexTypeDefinition); objects in the second layer would represent things defined by those schema components (e.g., ...ComplexType). Objects in the first layer would represent the incre- mental information (e.g., an additional sequence to be appended to the sequence from a base type); objects in the second layer would represent the net, resulting information (e.g., the combined sequence).
Adding a whole new layer might be overly complex, and not worth the effort of the resulting complexity. However, there is probably another solution.
The other solution is to just have two layers of properties (methods) in the logical object model (instead of two whole layers of objects).
The first layer of methods would represent the incremental information, at the level of schema component properties defined by the XML schema specification. The second layer would represent the net, resulting information.
For example, a ...ComplexType interface would officially represent both a complex type definition (a schema component) _and_ the complex type defined by that complex type definition. One method, in the lower layer, would list just the attributes defined in the complex type definition. Another method, in the higher layer, would list _all_ the attributes that apply to the complex type (the attributes from the complex type definition plus attributes from the base type).
Similarly, one method would return, say, the sequence model group specified in a complex type definition, while a corresponding higher- level method would return the resulting complex type's resulting implicit sequence (resulting from the base type plus the sequence model group specified in the complex type definition).
For another example, consider the XSSimpleType.getPatterns(). A lower- level version would list just the patterns specified in the simple type definition. The corresponding higher-level method would list all the patterns that applied to the simple type defined by the simple type definition (as the current getPatterns() methods does).
Given that the current JaxMeXS object model seems to be little bit mixed up, sometimes representing official schema components but sometimes instead representing the results of those schema components, I think JaxMeXS would be well served by clarifying what it is trying to represent, and it would be even more useful if we could find a way to represent both levels of information.
Daniel
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
