Michael,
While processing an ElementDeclaration I used;
XSObjectList xsObjectList = xsModel.getSubstitutionGroup(elemDecl);
to get the substitution groups and for each found substitution I
(recursevily) called this same method to process the
ElementDecalration of the substitution.
I was not aware of the extra complexity of "blocking".
So thanks again for your explanation
Dick Deneer
Op 31-jan-2007, om 22:56 heeft Michael Glavassevich het volgende
geschreven:
It's not an optimization. This is how substitution groups are
defined by
the XML Schema spec. Building this set isn't as easy you think. For
instance, B could block C but still be a member of A's substitution
group.
How could you "loop down" to find C from A if C is not in B's
substitution
group?
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [EMAIL PROTECTED]
E-mail: [EMAIL PROTECTED]
Dick Deneer <[EMAIL PROTECTED]> wrote on 01/31/2007
11:47:55 AM:
It is easy to "loop down" finding all possible substitutions. So for
me this optimization could have been left out,
because it makes it harder to show the original relations in the
schema to the user.
Thanks for your answer
Dick Deneer
Op 31-jan-2007, om 16:14 heeft Michael Glavassevich het volgende
geschreven:
Potential substitution group membership is transitive. Setting
aside the
conditions for exclusion (e.g. block="substitution"), if B is a
member of
A's substitution group and C is a member of B's substitution group
then C
is a member of A's substitution group. That's why "even" appears in
the
list returned for "myAbstract".
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [EMAIL PROTECTED]
E-mail: [EMAIL PROTECTED]
Dick Deneer <[EMAIL PROTECTED]> wrote on 01/29/2007
03:30:11 PM:
I have the following schema
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" >
<xsd:element name="root">
<xsd:complexType>
<xsd:sequence minOccurs="1">
<xsd:element ref="myAbstract"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="myAbstract" type="AAA" abstract="true"/>
<xsd:simpleType name="AAA">
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="1"/>
<xsd:maxInclusive value="9"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:element name="odd" substitutionGroup="myAbstract">
<xsd:simpleType>
<xsd:restriction base="AAA">
<xsd:enumeration value="1"/>
<xsd:enumeration value="3"/>
<xsd:enumeration value="5"/>
<xsd:enumeration value="7"/>
<xsd:enumeration value="9"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="evenAbstract" substitutionGroup="myAbstract"
abstract="true"/>
<xsd:element name="even" substitutionGroup="evenAbstract">
<xsd:simpleType>
<xsd:restriction base="AAA">
<xsd:enumeration value="2"/>
<xsd:enumeration value="4"/>
<xsd:enumeration value="6"/>
<xsd:enumeration value="8"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:schema>
So in this schema element myAbstract is substituted by element odd
or by the abstract element evenAbstract.
Element evenAbstract is susbstituted by element even.
When I ask the xsModel for the substitution groups of myAbstract I
get:
odd
evenAbstract
even
When I ask the xsModel for the substitution groups of
evenAbstract I
get:
even
I did not expect "even" in the susbstition list for myAbstract. I
know that in fact it is true that you susbtitute "even" for
myAbstract but with this kind of motivation you could also list
"odd"
as subsitution for evenAbstract.
So is this right behaviour?
-------------------------------------------------------------------
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]