OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [uddi-spec] Changes to UDDI Schemas and WSDL to support code generation


You've left out a vital part of the example, that being the minoccurs
attributes. Without them, the example doesn't make sense - there would
be no reason for creating such an ugly construct. I think it should look
like:

<choice>
   <element name="one" type="string" minoccurs="1"/>
   <sequence>
     <element name="one" type="string" minoccurs="0"/>
     <element name="two" type="string" minoccurs="1"/>
   </sequence>
</choice>

I really dislike this idiom, which is a nasty hack to support the idea
that we require at least one object, where that one may be chosen from
two types. It requires that the schema parser be coded with special
handling for this oddball construct. Unfortunately, I can't suggest a
better alternative that gives schema validation of the "at least one of
X or Y" rule. My personal preference would be to code the schema with
both elements as optional (minoccurs="0"), and state the requirement for
at least one in the text (but not validated by schema). Or maybe the
schema language could be extended to allow a construct like:

   <sequence minoccurs="1">
     <element name="one" type="string" minoccurs="0"/>
     <element name="two" type="string" minoccurs="0"/>
   </sequence>

Where the minoccurs on the sequence indicates that it cannot be empty. A
bit ugly, perhaps, but clearer, I think, than the hack we have today.

OK - now tell me I'm wrong :-)

Tony

-----Original Message-----
From: Matthew J. Dovey [mailto:matthew.dovey@oucs.ox.ac.uk] 
Sent: Sunday, 5 October 2003 23:02
To: Anne Thomas Manes; UDDI Spec TC
Subject: RE: [uddi-spec] Changes to UDDI Schemas and WSDL to support
code generation



> I agree with Matthew that lack of support for xsd:choice is a 
> bug in an 
> implementation -- whether or not it is a requirement in JAX-RPC.

Sorry, I should have clarified the particular bug, it isn't the choice
but the particular construct of have a choice of an element and sequence
where the sequence has an element with the same name as the other
element in the choice.

Axis (not sure about JAX-RPC) handles choice in the following way

A choice such as

<choice>
  <element name="one" type="string"/>
  <element name="two" type="string"/>
</choice>

Would generate a Java object with two properties

...
  String one;
  String two;
...

The serializer would throw an exception if both are non-null. This works
well.

However, in the case of

<choice>
   <element name="one" type="string"/>
   <sequence>
     <element name="one" type="string"/>
     <element name="two" type="string"/>
   </sequence>
</choice>

Our generated Java object has the following properties

String one;
String one;
String two;

Which wo'n't compile (without a little hand editing...)

Still a bug IMHO...

Matthew


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_wor
kgroup.php.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]