Mateo, Your suggestion doesn't work to get the name of the referenced named model group. Also, it is about the same as what I do in the second email with the source code. So back to the original question, how do get the name of a ref'd named model group from inside a complex type?
Elisha > -----Original Message----- > From: Matteo Vega [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 13, 2005 6:03 PM > To: xerces-c-dev@xml.apache.org; [EMAIL PROTECTED] > Subject: Re: Issues with PSVI interface(s) and group and attributeGroup > > > Elisha, > > Looks like yo're using the code from the SCMPrint > sample program. This is what u can do; when you are in > the XSParticle::TERM_ELEMENT if block (process element > section), you can further check if the element is a > complex type and recursively call ProcessParticle > function again: > > > XSTypeDefinition *xsTypeDef = > xsParticle->getElementTerm()->getTypeDefinition(); > if (xsTypeDef->getTypeCategory() == > XSTypeDefinition::COMPLEX_TYPE) > { > XSComplexTypeDefinition *xsComplexTypeDef = > (XSComplexTypeDefinition > *)xsParticle->getElementTerm()->getTypeDefinition(); > > ProcessParticle(xsComplexTypeDef->getParticle()); > } > > > I am new to Xerces, so there might be a better > solution. Nonetheless, this one works. > > Cheers, > > > Matt. > > --- Elisha Berns <[EMAIL PROTECTED]> wrote: > > 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] > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > --------------------------------------------------------------------- > 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]
