Jochen Wiedmann wrote:
On 5/16/05, Daniel Barclay <[EMAIL PROTECTED]> wrote:
JaxMeXS ... inserts the representation of an extra <sequence> element above the representation of the <choice> element, and leaves a null pointer in the particles list.
Hmmm. The use of xs:extension builds an *implicit* sequence,
consisting of the original content model and the added. In other
words, the first particle matches the content model of xs:any.
Are you referring to <xs:any> elements (the wildcards they define) or do you mean type xs:anyType?
>(It is, however, questionable, whether the "null" is a meaningful
representation of the xs:any content model.)
...Question is: What would be a better representation than null?
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.))?
Most of JaxMeXS's object model represents just incremental information, right? For example, if complex type t1 has an attribute, and complex type t2 extends t1 and adds an attribute, the XSComplexType object for t2 does _not_ list both attributes; it only lists what t2 adds. (One exception I notice is getPatterns().)
Therefore, you should probably be consistent and represent just incremental information in this case too. The getExtensions() pointers are sufficient to combine the information from a chain of multiple complex type _definitions_ to define a complex _type_ (the net results).
> The use of xs:extension builds an *implicit* sequence, > consisting of the original content model and the added.
But you don't build an implicit sequence in other cases, right?
That is, if a complex type extends another type (not xs:anyType), you don't add an extra XSModelGroup with a 'sequence' compositor to represent an implicit sequence consisting of the content model of the type that was extended and the added content from the type that was derived by extension, right?
Again, therefore, I think you should drop the extra sequence XSModelGroup (and the null particle pointer).
(I don't think you really want to represent that implicit sequence here, since JaxMeXS general doesn't represent that level of implicit information--that's for a higher level of processing.)
> In other words, the first particle matches the content model of xs:any.
That brings me to what's second:
The representation must be documented. Otherwise, how can users know what the representation means (e.g., how would a user know that null represented the content model of xs:anyType) or know what to expect for a given input?
(That's why I have complained about the documentation--some of it is simply wrong, and some important behavior isn't documented.)
Whatever you choose, make sure the user of your API can know what's supposed to happen.
Daniel
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
