Hi Elisha, "Elisha Berns" <[EMAIL PROTECTED]> wrote on 04/22/2005 03:09:43 PM:
> > > > > > Though I have yet to get any response to my previous email this post > is > > > to get clarification, at least theoretically, how the XSParticle > class > > > needs to handle references to both 'group' and 'attributeGroup' > inside > > > of complexType declarations... > > > > > > Currently when parsing an XSCompleTypeDefinition object the > > > getParticles() method returns an array of XSParticle objects. These > > > objects can then be queried whether they are XSElementDeclarations > or > > > XSModelGroup by calling getTermType(). If it is an XSModelGroup, it > can > > > be queried further to provide its COMPOSITOR_TYPE, which may be > > > COMPOSITOR_SEQUENCE, COMPOSITOR_CHOICE or COMPOSITOR_ALL. But if it > is > > > a *named model group* the XSModelGroup interface appears to not > provide > > > any information. Nor does the XSParticle interface provide any type > > > information for the *named model group* referenced. > > > > > > In light of this it would appear that this is an omission on the > part of > > > (at least) these two interfaces: XSParticle and XSModelGroup. Well, not quite. :) The first thing to keep in mind is the purpose of this API: It's not to provide an application with every detail of XML Schema documents. There's lots of other things you can't get at--values of "form" attributes, annotations inside element references, any non-XML schema attributes (unless you enable the right feature), and lots more. What the API *does* try to do is mirror, as closely as possible, the information that schema components are supposed to carry, as described by XML Schema Structures in its 3.x.1 sections. So if you look at the information carried by Model Group components in http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#Model_Group_details, you'll notice that they don't know their names and don't have any reference to the model group definitions that spawned them (if they had any). This is a good thing for Xerces, since internally we "in-line", if you will, the contents of the model group definitions thus referred to. Whether this is a bug or feature is somewhat in the mind of the user I guess :), but this is expected behaviour. > > > Currently, besides things not working this way, there is a certain > > > weirdness to how they do work: if there is a named model group > > > referenced inside the complexType then recursively fetching the list > of > > > particles will fetch all the elements from the referenced named > model > > > group, even though none of those elements are particles inside the > > > complexType. In fact, they are. They become properties of the complex type by virtue of there having been a reference to a model group definition in the XML representation of the schema. > > > For example: > > > > > > ProcessParticle(XSParticle* p) > > > { > > > if ( term_type == XSParticle:TERM_ELEMENT ) > > > { > > > // process element > > > } > > > else if ( term_type == XSParticle::TERM_MODELGROUP ) > > > { > > > XSModelGroup* pMG = pParticle->getModelGroupTerm(); > > > if ( pMG == 0 ) > > > return; > > > > > > XSParticleList* pPL = pMG->getParticles(); > > > if ( pPL == 0 ) > > > return; > > > > > > unsigned int nSize = pPL->size(); > > > for ( unsigned int i = 0; i < nSize; i++ ) > > > { > > > ProcessParticle( pPL->elementAt(i) ); > > > } > > > } > > > } > > > > > > So what's the design rationale here? Is this really the way it's > > > supposed to work? Frankly, it seems that this breaks the design > > > paradigm of other PSVI classes because for all other types > referenced > > > from an enclosing type, such as an XSElementDeclaration inside an > > > XSComplexTypeDefinition, you need to first get the object to then > get > > > its type definition, name, etc. But here you don't really, and > can't > > > get the XSModelGroup object for the named model group, but you can > still > > > get its contained elements. Like I wrote above, that's because you're not looking at the original model group definition. It's been cloned, if you will. An artifact both of how XML Schema defines these things, and what's easiest from the perspective of an implementation. BTW, if you've looked at the code, you've probably already concluded that the implementation of these APIs is a touch baroque. That's true; they're built as wrappers on the pre-existing Xerces-C grammar representations. For a cleaner implementation built right along the lines of the schema specs (so that the implementation of this API falls out naturally), take a look at the way Xerces-J did things. Xerces-J had a thorough-going rewrite a while back, and this enabled them to build this in from the ground up. Cheers, Neil Neil Graham Manager, XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
