Radu
I am struggling trying to understand why I am unable to retrieve some of
the identity constraints from in my compiled schema. I have been
traversing the content model of each complex type as you described
below, and am still finding that many of the constraints are missing.
After some investigation, I was led to think it was possibly due to
pointless particles in the schema that were being ignored - but I still
see the particles that have the constraints defined against them.
Clearly I am still missing something. The following test schema
illustrates what I am seeing:
<xs:element name="testdesign" type="con:testdesign"/>
<xs:complexType name="testdesign">
<xs:sequence>
<xs:element name="testroot" type="con:testroot">
<xs:key name="elementAKey">
<xs:selector
xpath="./con:elementA"/>
<xs:field xpath="@name"/>
</xs:key>
</xs:element>
<xs:element name="testRoot2" type="xs:string"/>
</xs:sequence>
</xs:complexType>
When there is more than one element in the above sequence, the
constraint "elementAKey" cannot be found - nor can any particles for the
"testdesign" type. If I remove element "testroot2", then it is found.
I am checking for constraints as follows (note: only global types are
defined):
for(SchemaType type:sts.globalTypes())
{
checkIdentityConstraints(type);
}
private void checkIdentityConstraints(SchemaType _st)
{
if (_st.getContentType() == SchemaType.ELEMENT_CONTENT
|| _st.getContentType() == SchemaType.MIXED_CONTENT)
{
SchemaParticle particle = _st.getContentModel();
switch (particle.getParticleType())
{
case SchemaParticle.ELEMENT:
printParticle(_st);
break;
case SchemaParticle.CHOICE:
case SchemaParticle.SEQUENCE:
case SchemaParticle.ALL:
SchemaParticle[] pchildren =
particle.getParticleChildren();
if (pchildren != null)
{
for (SchemaParticle pchild : pchildren)
{
SchemaType childType = pchild.getType();
if(childType!=null)
{
printParticle(childType);
checkIdentityConstraints(childType);
Can you explain this behavior? At this point I am not sure if the
problem is with code, schema, or something else...
thanks again for any assistance
Les
-----Original Message-----
From: Walker, Les (GWRTP:3798)
Sent: Tuesday, May 15, 2007 9:50 AM
To: [email protected]
Subject: RE: schemaIdentityConstraint to schemaType mapping issues
Radu
Thank you for the guidance, it has added new layers to my understanding
of this area.
I found the problem was in the schema where the constrained element
contained on one required child element - which apparently causes the
compiler to ignore it in its mapping. This was news to me... something
like
<xs:element name="foo" type="foo1">
<xs:key name="subtreeKeyConstraint">
<xs:selector xpath=".//constrainedFooChild"
<xs:field="@f1"/>
</xs:key>
</xs:element>
<xs:complexType name="foo1" final="extension">
<xs:complexContent>
<xs:extension base="baseType">
<xs:sequence>
<xs:element name="fooChild"
type="fooChildType"/>
</sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="fooChildType" final="extension">
<xs:complexContent>
<xs:extension base="someBaseType">
<xs:sequence>
<xs:element
name="constrainedFooChild" type="otherChildType" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
<xs:attribute name="f1"
type="xs:string"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
I still plan to adapt my code to use the approach you outlined, it seems
like a more generalized strategy.
thanks again
Les
-----Original Message-----
From: Radu Preotiuc-Pietro [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 08, 2007 8:46 PM
To: [email protected]
Subject: Re: schemaIdentityConstraint to schemaType mapping issues
What the code that you posted does is retrieve the identity constraints
from types that have only one element in their content model. In
particular, this works for constraints that are declared on top-level
elements but not for others.
Since you want not only the constraints, but also their scope, this gets
complicated (almost anything related to Schema identity constraints gets
complicated very quickly). The reason is that identity constraints on
local elements can have different scopes depending on the structure of
the instance document being validated.
So I would start with a set of all the global elements
(SchemaTypeSystem.getGlobalElements()). Then do
element.getIdentityConstraints()
to get the set of identity constraints on each of the elements. Then
SchemaType st = element.getType();
if (st.getContentType() == SchemaType.ELEMENT_CONTENT ||
st.getContentType() == SchemaType.MIXED_CONTENT)
{
SchemaParticle p = st.getContentModel();
switch (p.getParticleType())
{
case SchemaParticle.ELEMENT:
// A local element, continue with checking it for id constraints
and recurse
case SchemaParticle.CHOICE:
case SchemaParticle.SEQUENCE:
case SchemaParticle.ALL:
// Look for more elements among the particle children
}
}
So you need to recurse inside the content model of each global element's
type, find all local elements among other kinds of particles (which is
another recursion) and then repeat. Special care must also be taken
because elements can reference each other and so you can end up with
infinite recursion. So you need to stop once you find an id constraint
that you already "know about" or find some other exit condition that
makes sense in your case.
Good luck and let me know if anything that I said above doesn't quite
make sense.
Radu
On Tue, 2007-05-08 at 09:51 -0400, Les Walker wrote:
> A couple of questions
>
> 1.
> I am having a problem where I cannot find certain
> schemaIdentityConstraints in the generated code for our XSD. Our code
> walks the schema and derives a mapping from the constrained element to
> its actual constraint and scope in the model. This is working for the
> vast majority of cases, but for some of our top-level elements they
> cannot be found. I am currently checking for the presence of
> constraints by walking the global schemaTypes via the containment
> hierarchy in the tree. Each complex type (we use named types only) is
> checked for constraints as follows:
>
> private SchemaIdentityConstraint[] getConstraints(SchemaType
> _schemaType)
> {
> SchemaIdentityConstraint[] constraints = null;
> if(isLocalElement(_schemaType))
> {
> SchemaLocalElement local =
> (SchemaLocalElement)_schemaType.getContentModel();
> constraints = local.getIdentityConstraints();
> }
> return constraints;
> }
>
> Can anyone tell me what am missing or doing wrong? Are there other
> component types I have to check for constraints?
>
> 2.
> Something else I have noticed is that the generated identity
> constraint for an element in the schema is actually associated against
> its containing schemaType - which makes it hard to use ./xxx in a
> constraint definition - since the scope in the generated code is one
> step higher than its original definition. Is this intentional? If so,
> I would be interested to know why it is done this way and possibly a
> strategy to manage these scopes in a way consistent with the XSD.
> Currently I have to wrap my selector access with the extra inserted
> element name - this works, but seems awkward.
>
>
> any guidance is greatly appreciated
>
> LW
>
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
