This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Journey To Enterprise Agility and have Daryl Kulak & Hong Li on-line!
See this thread for details.
Win a copy of The Journey To Enterprise Agility this week in the Agile and Other Processes forum! And see the welcome thread for 20% off.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Junilu Lacar
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Ganesh Patekar
  • Tim Moores
  • Pete Letkeman
  • Stephan van Hulst
Bartenders:
  • Carey Brown
  • Tim Holloway
  • Joe Ess

Cant make xsd element required  RSS feed

 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i have an xsd with elements in it The only element i cant set to required is 'ggg' and its of a type xs:unsignedShort, the othere elemets work fine and the java code sets it to required=true, just this one is bothering me, any ideas

part of xsd:


part of the xsd type:
 
Ranch Hand
Posts: 710
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem is probably due to the incorrect construction of the schema at this stage. Any code generation approach related to schemas is based on the schemas being properly validated.

                        <xs:element name="ccccc" type="typer:cccc"/>
                            <xs:complexType>
                                <!-- etc etc... -->


If the line of xs:element name="ccccc" is correct, it implies that you have xs:complexType as direct child element of xs:sequence : this is incorrect.
If the line of xs:element name="ccccc" has a typo of ending / which implies it is a self-closing element which should not be there, it is still incorrect because inline type definition (the following xs:complexType etc...) will not be compatible with existence of @type="typer:cccc" attribute : either one or another.

After you've corrected it and supposing that there is no other schema-specific mistake, the question could be resolved by itself.
 
Mikael Molin
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes it is a typo / should not be there.

right now this code ggg that reference to the typer'GGG':
<xs:simpleType name="GGG">
    <xs:restriction base="xs:unsignedShort"/>
</xs:simpleType>

generates java:

but if i chande the simpleType 'GGG' to a xs:dedimal it makes the java code required. like this:
<xs:simpleType name="GGG">
    <xs:restriction base="xs:decimal"/>
</xs:simpleType>

generates java:


same goes for xs:string
so this is what makes me confused, just by changing the simpleType makes it required or not .
I was thinking that maybe this line at the beginning of the xsd has something to do with it, cause we are refering to Collectum and the might have restrictions but i am not sure.

 
g tsuji
Ranch Hand
Posts: 710
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Yes it is a typo / should not be there.


In that case, the following xs:complexType etc are still incompatible with the existence of @type="typer:cccc". Having that posted will confuse further readers. It is still incorrect, but I leave you to sort it out as I suspect you've a better blueprint and valid schema behind the screen.


right now this code ggg that reference to the typer'GGG':
<xs:simpleType name="GGG">
    <xs:restriction base="xs:unsignedShort"/>
</xs:simpleType>

generates java:



The code generated will deliver as far as the idea of "required = true" is concerned for a subtle reason. The xs:unsignedShort would be mapped to java type "int". Now, int is an atomic value type, and it is implicitly initialized to 0. It would never ever be null as any other object types. When jaxb marshalling the object graph, the element, say ns:x, having the type GGG will always be outputted. If you haven't assign any value to it, it will output <ns:x>0</ns:x>. This you can verify it with your existing code already. There won't be any circumstance where the output would miss out the element ns:x. This is essentially what you wish to have. That means even by default required being false, the practical result will be exactly footing the bill as if required = true.

Now, what if you ask that you want at all cost having the required being true explicitly. You can do it like this.

The magic here is that xs:integer would be mapped to java.math.BigInteger. Without assigning it a value, it would be null and resulting in jaxb engine not marshalling it out, hence, an invalid document being outputted. Hence, the required will be enforced somehow via the ObjectFactory and some other locations in the code probably...

Again, all these can be verified a posteriori if you run the code.
 
Mikael Molin
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes i have a better blueprint and a valid schema here beside me.

I understand now and will use:

the code above will give me the output <ns:x>0</ns:x> and thats works fine, i didnt want it to be null and  jaxb not marshalling it.

Thanks for your answers.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!