Re: Action 2003-01-21 for Umit

Martin Gudgin wrote:

>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.
>
Point taken. It appears that I developed my schemas with a buggy tool it 
appears which did not take into account expending the group defn.
 
I have to think a bit more about choice.xsd. However, the 
recurring-group.xsd can be "fixed". It does not need to have xsd:all. 
The recurrimg group definition could be expressed with an xsd:sequence. 
This does not change the intent of making this as a recurring group.

>
>Regards
>
>Gudge
>
--umit

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

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com