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]
