Hi Neil,
Thanks for the detailed reply. It at least clarified the Xerces view of
things, which is good. I reviewed your comments and the link to the XML
Schema spec that you included, and at the risk of sounding like some
bone-headed bozo there are some things that still don't make sense
here... And forgive me if this comes across like some tedious review,
I'm just trying to extract more clarity than seems possible from the
documents themselves.
Well here's my confusion:
The schema spec creates potential confusion by using the term "model
group" for two kinds of things: a named model group and an unnamed model
group. And then proceeds to define similarities and differences between
them, which only makes reading the document more confusing. The named
model group and how it is represented in the PSVI interfaces is what
I've been questioning.
But the link you sent me deals with the latter, an unnamed model group
that is constrained by a compositor of {all, choice or sequence}.
Elsewhere in the schema spec (section 3.8.2) model groups are
specifically defined by a {all, choice or sequence} compositor and child
particles which can be " <all>, <choice>, <sequence>, <any>, <group> or
<element>". The <group> item can be a particle provided that it is a
"<group> not immediately within <schema>" (section 3.9.2), which seems
to mean that a reference to a named model group is a particle when it is
a child of some unnamed model group, but the DEFINITION of the named
model group IS NOT a particle, since it is a direct child of <schema>.
And if so, there is a distinction between the definition of a named
model group and a reference to a named model group: one is not a
particle and the other is. If a <group> item can only be a particle
when it appears as a reference to a named model group inside an unnamed
model group, then really it is a unique term type inside an unnamed
model group (like element). And if it is a unique term type then it
needs to be treated as such (section 3.8.2). Obviously you disagree on
this point, buy why? What is wrong in my reading of the spec?
So back to my issue: nowhere else do the PSVI interfaces treat a
reference to a type as if it is the type's definition or declaration, so
why here regarding named model groups is this *correct*? If the
definition of a named model group is not a particle, then a <group
ref="xx"> that is a particle should enable:
1) calling getParticles() should return NULL (no recursive definition,
just like element does not have a recursive definition)
2) calling pParticle->getTermType() when the particle is a named model
group should give a unique term type for a named model group
3) calling pParticle->getModelGroupTerm() (or getNamedModelGroupTerm())
should give its type object which is an XSModelGroupDefinition.
I know my questions are probably annoying, but the spec appears confused
at best on this issue, as does the interface.
Thanks for some more clarity here,
Elisha Berns
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
