RE: Action 2003-01-21 for Umit

OK, reworking recurringgroup.xsd to be as attached, here is a possible binding:
 
Assumes that the operation refers to the type embeddedExample. Also assumes in scope ns decls as before:
 
1.
 
<!-- this binds the entire type as the type of soap:Body -->
<soap:body xpath='*' />
 
 
2.
 
<!-- this binds a subset ( doesn't bind the recurring group ) -->
<soap:body xpath='p:description[1] | p:id[1] | p:letter[1]' />
 
3.
<!-- binds the recurring group but limits to 2 occurences -->
<soap:body xpath='p:description[3 >= position() >= 1] | p:id[3 >= position() >= 1] | p:letter[3 >= position() >= 1]' />
 
 
As I mentioned to you when we discussed this, I think the content model is actually bad markup design, I would nest the recurring group inside some other element.
 
We could also produce a binding that provides a wrapper element for all the above.
 
For the record, if *I* was binding any of these schemas types, I'd just bind the whole thing and the message processing code would deal with variations in message serialization.
 
Gudge

________________________________

From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com]
Sent: Mon 03/03/2003 17:03
To: Martin Gudgin
Cc: www-ws-desc@w3.org
Subject: 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