RE: Action 2003-01-21 for Umit

OK, here are suggested bindings for one of the examples you posted.

background-check.xsd

Assumes that the operation refers to the background-record GED. Also
assumes an in-scope ns decl for wsdl soap binding and tns of
background-check.xsd

1.	

<!-- this binds the entire element to be a child of soap:Body -->
<soap:body xpath='*' />

2.	

<!-- this binds a subset of the children of the GED --> 
<soap:body xpath='p:company | p:address[1] | p:person-info |
p:address[position()!=1] | p:credit-rating' />

3.

<!-- as above but also specifies that p:report is serialized seperately
--> 
<soap:body xpath='p:company | p:address[1] | p:person-info |
p:address[position()!=1] | p:credit-rating' /> 
<swa:data xpath='p:report' />

Note that the subset examples are still legal per the schema type. I
only bind immediate children of the GED. One could use XPath to bind to
arbitrary depth but I'm not sure we need that for these examples.

Neither of the other two schemas you posted are legal, so I don't think
it's reasonable to try to work up binding examples for them.

For the record given the following: 

A) Can't nest an xsd:all inside xsd:choice or xsd:sequence.

B) Can't have two element decls in the same context with different type
but same name.

choice.xsd is illegal for A and B, while recurring-group.xsd is illegal
for A.

Regards

Gudge

> -----Original Message-----
> From: Martin Gudgin [mailto:mgudgin@microsoft.com]
> Sent: 27 February 2003 18:40
> To: Umit Yalcinalp
> Cc: www-ws-desc@w3.org
> Subject: RE: Action 2003-01-21 for Umit
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com]
> > Sent: 27 February 2003 17:29
> > To: Martin Gudgin
> > Cc: www-ws-desc@w3.org
> > Subject: Re: Action 2003-01-21 for Umit
> 
> <SNIP/>
> 
> > Before starting to debate the rest, lets agree on the common 
> > assumptions first.
> > 
> > In the January f2f, the idea explored was that when a single schema 
> > replaces the message construct, the concept of parts was going to be

> > moved from the abstract to the concrete binding. For some of us, 
> > having *multiple* parts is necessary in the binding.
> 
> By which you mean what? Surely a binding just describes
> concretely what a message looks like on the wire... Are you 
> just asking for the ability to say 'this element goes in the 
> body, that element goes in a header'? Or 'this element goes 
> in the body, that element goes as an attachment'? Or are you 
> asking for more than that?
> 
> > So the exercise was to come up with schema
> > examples and explore how they will exhibit themselves in
> the binding!
> 
> That much I understood, but the discussion of 'parts' confused me.
> 
> 
> > 
> > Given this assumption, the idea is to explore how the parts are 
> > going to reappear in the binding as they would be dissappearing from

> > the abstract. So a "mapping" is necessary.
> 
> So, hopefully, by 'mapping' you mean specifying which
> elements/attributes go where...
> 
> > 
> > My task was to present complex schema examples. You guys were going 
> > to show the mapping in the binding. Am I missing something?
> 
> Obviously I was...
> 
> Gudge
> 
>

Received on Monday, 3 March 2003 09:08:55 UTC