Well, The investigation should be pretty simple, and if there is a need (which I doubt) I can provide the core method to verify my observations about how the XSPariticle handling is not correct, not in theory and not in the code.
Elisha > -----Original Message----- > From: Gareth Reakes [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 21, 2005 4:05 AM > To: c-dev@xerces.apache.org > Subject: Re: FW: Issues with PSVI interface(s) and group and > attributeGroup > > Hi, > > I would have to go and investigate, is that the case with everyone > else > as well? If so, we will have to draw straws :) > > Gareth > > Elisha Berns wrote: > > All, > > I never got any response to this email that I posted about 3 weeks ago. > > Can someone knowledgeable respond? > > > > Thanks, > > > > Elisha Berns > > > > Hi, > > > > 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. Shouldn't > > XSParticle have a constant for a named model group (i.e. > > XSParticle::TERM_NAMED_MODELGROUP) that lets you know that the particle > > is a reference to a named model group. And then XSModelGroup can > > provide the type information for that named model group when calling: > > > > XSModelGroup* pMG = pParticle->getModelGroupTerm(); > > pMG->getTypeDeclaration(); > > > > which will then give its namespace and name, etc.? > > > > 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. 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. > > > > So first what's theoretically correct here, and second doesn't this need > > to be fixed? > > > > Elisha Berns > > [EMAIL PROTECTED] > > tel. (310) 556 - 8332 > > fax (310) 556 - 2839 > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > Gareth Reakes, Managing Director Parthenon Computing > +44-1865-811184 http://blog.parthcomp.com/xerces > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
