Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Blocker
-
Resolution: Unresolved
-
Affects Version/s: 0.9.3.21
-
Fix Version/s: None
-
Component/s: XML code generator
-
Labels:None
-
Environment:Operating System: Windows 2000
Platform: PC
-
Bugzilla Id:1054
-
Number of attachments :
Description
Sorry for the blocker severity. It is a blocker for me, but perhaps not in
Castor's view!
I have an XML Schema that describes a soccer pitch having red and black shirted
players. The XML stream order of player elements combined with a Midfield
element attempts to determine how may of each of the two team members are on
either side of Midfield using the order of the stream to count. So, with this
XML stream:
<?xml version="1.0"?>
<SoccerPitch xmlns="WorldCup" xmlns:ex="WorldCup"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="WorldCup ../xsd/SoccerPitch.xsd">
<RedChap/>
<BlackChap/>
<Midfield/>
<RedChap/>
<BlackChap/>
</SoccerPitch>
I would expect order to be maintained when unmarshalled to show two players on
either side of Midfield, one from each team. The expected print out
(Parenthesis encapsulate total player count):
RedChap(0)
BlackChap(1)
Midfield
RedChap(2)
BlackChap(3)
The following schema that I Castorize seems to constrain the stream properly:
<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="WorldCup" xmlns="WorldCup"
elementFormDefault="qualified">
<xsd:element name="SoccerPitch">
<xsd:complexType>
<xsd:annotation>
<xsd:documentation>
Type to deal with a soccer pitch having Red and Black jersey players.
The hope is to allow for players to play both sides of Midfield.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element name="RedChap" type="xsd:string"/>
<xsd:element name="BlackChap" type="xsd:string"/>
</xsd:choice>
<xsd:element name="Midfield" type="xsd:string"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element name="RedChap" type="xsd:string"/>
<xsd:element name="BlackChap" type="xsd:string"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Catorizing produces the expected 2 Choices and access to the Midfield element.
However, the first choice always snarfs up ALL players leaving the second
choice collection with nothing to show. I generate the following output:
RedChap(0)
BlackChap(1)
RedChap(2)
BlackChap(3)
Midfield <---- Red Card!
Keith Visco graciously replied to this problem for my on castor-dev:
> Castor will probably treat your case as an "all" which means sequence
> order will probably not be retained. You should expect the sequence
> order to be maintained, but I don't think Castor will maintain it in
> this case.
The output above was produced using this Java source:
private void printDocument(SoccerPitch doc) {
int elements = 0;
// (
// <---------------------- s ---------------------->
// (RedChap|BlackChap),Midfield,(RedChap|BlackChap)
// <------- sc1 -----> <------ sc2 ------>
// )
if (doc.getSoccerPitchChoiceCount() > 0) {
for (Enumeration sc1Enum = doc.enumerateSoccerPitchChoice();
sc1Enum.hasMoreElements()![]()
}
if (doc.getMidfield() != null)
System.out.println("Midfield");
else
System.out.println("Error! Should have Midfield somewhere...");
if (doc.getSoccerPitchChoice2Count() > 0) {
for (Enumeration sc2Enum = doc.enumerateSoccerPitchChoice2();
sc2Enum.hasMoreElements()![]()
}
System.out.println("");
} // void printDocument()
Kind Regards,
Greg K
Gregory, we'll try to have a patch in soon. It might not make Monday's release
however.