axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Yegerlehner" <>
Subject Re: Philosophical question about WSDL and web service frameworks
Date Tue, 15 Jan 2002 07:21:46 GMT
Hello Anne, Jan, Russel and Rich-

Thanks very much for considering my argument and for your thoughtful
replies. I'll combine my reply to your various points and questions below.

Russel said:
> AXIS DOES want to support all valid schema types, but we're not
> there, yet.

I'm very glad to hear that!

Russel said:
> To work our way there, we had to decide what to do first.  One
> of the drivers of this is the JAX-RPC spec.


Jan proposed:
> public class OrderResponseHeader
> {
>   ...
>   public class Choice1
>   {
>       public static int DISC_ORDERHEADER = 1;
>       public static int DISC_CHANGEORDERHEADER = 2;
>         public int discriminator;
>         public OrderHeader originalOrderHeader;
>       public ChangeOrderHeader changeOrderHeader;
>   }
>    ...
>Any comments ?

OK that works. I have several reservations about this:
1. There's nothing in the syntax that enforces the semantics. That is, what
is there to tell the naive user of the code that at most one of orderHeader
and changeOrderHeader is non-null?  I suppose he'd learn (perhaps the hard
way) that if the class name is "ChoiceN" then that's the situation. But I
think it would be better if the mutual exclusivity of the composited
instances was enforced in the class structure.
2. The discriminator seems superfluous in that one could just as easily test
for non-null as compare the discriminator integer to the enumerated values.
3. It doesn't round-trip. That is, is there anything in this class to tell
the WSDL generator that it should emit a choice compositor here as opposed
to anything else (sequence).  I suppose there are a lot of things in
schema-to-java mappings that are "lossy" so perhaps that's not worth
dwelling on.
4. Presumably you'd have to do something different if maxOccurs was >1 on
OrderHeader, e.g.:

   <element type="OrderHeader" name="OriginalOrderHeader" maxOccurs=6/>

In this case, would you emit an "OrderHeader[] originalOrderHeader"?

I don't suppose any of those concerns is a show-stopper.

Russel said:
> Another item that you use that we don't support is xsd:NMTOKEN.

As long as the schema to java mapping is a bit lossy, I'd suggest that any
of the specializations of xsd:string (xsd:NMTOKEN,  xsd:NCName, etc) just be
demoted to a java string. Some day it would be nice if every constraining
facet in every simple type could be preserved in code. But until then...

Russel said:
> If you have some suggestions as to how we'd map these to Java, we'd like
> hear them.

and Rich Said:
> If you would like to supply me with a reasonable
> mapping between xsd:choice and java, I may be able to make this change in
> the emitters (and influence JSR-101).

Thank you; that's an invitation I can't resist! I will be happy to attempt
this. I will have to squeeze it in so it may be a few days.

James Yegerlehner
Omniopera: XML Schema and WSDL Authoring Software

View raw message