castor

• 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

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()

{ SoccerPitchChoice sc1 = (SoccerPitchChoice)sc1Enum.nextElement (); SoccerPitchChoiceItem sc1Item = sc1.getSoccerPitchChoiceItem(); if (sc1Item.getRedChap() != null) System.out.println("RedChap(" + elements++ + "): " + sc1Item.getRedChap()); else if (sc1Item.getBlackChap() != null) System.out.println("BlackChap(" + elements++ + "): " + sc1Item.getBlackChap()); }

}
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()

{ SoccerPitchChoice2 sc2 = (SoccerPitchChoice2)sc2Enum.nextElement (); SoccerPitchChoice2Item sc2Item = sc2.getSoccerPitchChoice2Item(); if (sc2Item.getRedChap() != null) System.out.println("RedChap(" + elements++ + "): " + sc2Item.getRedChap()); else if (sc2Item.getBlackChap() != null) System.out.println("BlackChap(" + elements++ + "): " + sc2Item.getBlackChap()); }

}
System.out.println("");
} // void printDocument()

Kind Regards,
Greg K

• Assignee:

  Unassigned

  Reporter:

  gregory_kedge

• Created:

  08/Oct/02 10:14 AM

  Updated:

  31/Mar/07 11:20 AM