RE: Action 2003-01-21 for Umit

Thanks for the post, Umit.  You've obviously put a lot of thought into this,
and I'm convinced from your description that it will be very difficult to
map arbitrarily complex schemas to parts.

That said: why would one want to be able to do that?  What is the use case
here?

I can understand Gudge/Roberto's argument: we can take complex message/part
descriptions and map them to schema and define a binding for them.  In
addition, we can have more complex descriptions of the message/part
combination (cardinality, etc), and leverage schema to do that.

However, why would a web service designer need to take an arbitrary schema
type and map that back to message/part?  If I have a complex XML type that I
need to send, then I can send that as a single type, right?   Why do I need
to split it into parts?  If I have a complex java signature or other
service, it is pretty easy to map that to schema, but not the reverse (as
you've shown).

What am I missing?

Don

> -----Original Message-----
> From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com]
> Sent: Monday, February 03, 2003 7:08 PM
> To: www-ws-desc@w3.org
> Subject: Action 2003-01-21 for Umit
> 
> 
> Folks,
> 
> As promised, I am sending couple of xsd files as a basis for 
> discussion 
> as my action item
> from F2F [1]. See also the thread on removing message 
> starting from [2]. 
> Our position can be found in [3].
> 
> What I want to explore are the issues that would face us if 
> we replaced 
> message/part constructs by a single schema  and then shifted the 
> responsibility of defining parts in the abstract to defining mapping 
> relationship(s) in concrete bindings instead. To refresh your memory, 
> what we decided to do in the  F2F was to look at some examples and 
> discuss how the bindings and mapping  definitions will look 
> like where 
> message parts are now part of the binding. This is to explore the 
> implications of [2] further.
> 
> My initial goal was to produce a complex schema where mapping 
> the schema 
> to concrete parts would be difficult. However, to discuss the 
> questions/issues presented below, I  came up with three. 
> Naturally, this 
> list can be extended. We need  Gudge and Roberto (JustSayNoToMessage 
> gang) to propose some answers to the questions presented below along 
> with concrete binding examples.
> 
> I made the following observations during this exercise. A straight 
> forward way of generating mappings for any type of schema is non 
> trivial. The most important fact is that arbitrary schema constructs 
> (esp. xs:choice, xs:group, xs:all) in a schema enable making multiple 
> bindings possible since parts can be obtained following 
> different choice 
> paths or order in a schema. Further, we may also need to require 
> constructs other than elements/types to be mapped to parts. 
> See (b) and 
> (c) below.
> 
> As parts are no longer in the abstract defn, it is also not 
> obvious what 
> kind of rules should be applicable to producing "valid" bindings. The 
> binding must ensure the uniqueness of the wire
> representation. Conventions will need to be adopted 
> especially dealing 
> with referencing unordered schema components instead of 
> relying on the 
> order of parts. I would also expect that the mapping would 
> need to name 
> parts uniquely in the binding.
> 
> There is also a need to define the validity of a mapping. 
> There are two 
> related issues (1)
> Should bindings cover the entire schema or can part mapping be done 
> using only certain parts of the schema?  (2) What are the 
> mapping rules 
> to ensure schema compliance? Not all part combinations that can be 
> arbitrarily identified by a "reference mechanism" from a schema,
> such as XPath, may constitute a valid composition of parts 
> for a binding 
> as a signature. See (a) for these questions.
> 
> The last but the most important issue is the implications for web 
> service design as a consequence of removing message/parts as well as 
> embedding the represention of attachments within the abstract 
> definition.
> 
> (a). (background-check.xsd) This example is actually very 
> simple. It is 
> a schema that represents a background check record for a company 
> regarding a person including his/her last known addresses and the 
> person's credit rating. A report may be also included. I 
> tried to reuse 
> a type which has different semantics in the schema, company 
> address vs 
> person's address, introduced cardinality, used a simple 
> attachment, etc.
> 
> I chose this example to highlight a point that was discussed 
> during the 
> f2f meeting.  We discussed that the existing WSDL design with 
> parts can 
> directly map to an a xs:complexType defined by a sequence of 
> xs:elements 
> where each element (or its type) in the sequence can be mapped to a 
> part. (WSDLwithMessageAndParts -> Schema).  We can ensure a unique 
> mapping this way, it is 1-1. Starting from a WSDL, it is easy 
> to derive 
> the schema.
> 
> This simple example shows  that the reverse, i.e. OneSchema -> 
> MultiplePartsInBinding, is non-trivial, because this mapping 
> is 1-many 
> even for simple schemas. There are different ways to map schema 
> components to a set of possible parts.
> 
> Below are three possible mappings for the background check schema. (I 
> define them abstractly by using the element name for each 
> part for the 
> sake of discussion here as the precise way of naming and 
> designating a 
> part with XPath that references an element/type will be proposed by 
> others not me ;-))
> 
> 1. operation (company, address, person-info, address*, credit-rating, 
> report)
> 2. operation (company, address, social-security-no, address*, 
> credit-rating, report)
> 3. operation (company, address, firstname, middlename, lastname, 
> address*, credit-rating, report)
> 
> I claim 2 and 3 are equally valid as 1. Therefore, given one 
> schema, we 
> have at least 3 possible bindings. On the other hand, the 
> next mapping 
> (4) does NOT appear to be valid according to the schema:
> 
> 4. operation (company, address, social-security-no, firstname, 
> middlename, lastname, address*, credit-rating, report)
> 
> This brings the question I proposed earlier: how we can 
> define rules so 
> that a proposed mapping is not violating the schema 
> constraints itself?
> 
> Further,  would the binding
> 
> 5. op(company, address)
> 
> be valid? Do we expect the parts generated from a schema to 
> "encompass" 
> all schema components derivable by traversing the schema or 
> subsets can 
> be considered valid as well?
> 
> How about
> 
> 6. op(company, address, address)
> 
> Note that the same schema can become more interesting for mapping 
> purposes if "test:addressType" was an anonymous type defined 
> within the 
> global element "test:address" and this global element was 
> reused within 
> "test:backgroundType" instead.
> 
> This example also brings forward my big issue wrt design of web 
> services. From a design point of view, it would be way 
> simpler to think 
> about these three examples above as possible operation 
> signatures rather 
> than  mappings to three (or possibly more) different bindings which 
> would ALSO need to be valid wrt to the schema that they were derived 
> from. I would
> claim that people naturally design with parts and three different 
> operations when they need different signatures rather that trying to 
> define multiple mappings at the concrete binding level. When 
> we remove 
> parts, this way of designing this particular service is 
> complicated as 
> it is not natural to expose a web service functionality only in the 
> binding.  We need the message/part abstraction in the 
> abstract level as 
> well.
> 
> Now lets suppose the "test:report" element is an attachment. 
> According 
> to our discussion at the f2f, we would need to mark this schema part 
> within the abstract definition with a media-type.  It seems 
> that we seem 
> to be solving a much bigger problem of embedding non-XML 
> constructs (and 
> type system) within schema (actually XML) which was cleanly 
> addressed by 
> having a separate part concept in the first place from the 
> WSD point of 
> view. How do we envision validation to take place in this 
> case? I make 
> the observation such that removing message/parts moves the 
> responsibility from the abstract to the concrete binding for defining 
> parts but also moves the problem of identifying the type of the 
> attachment from the concrete to the abstract level! 
> 
> 
> (b). (choice.xsd). This example illustrates that the current way of 
> thinking about mapping parts to only elements and types would need 
> revision. This is a schema example that contains a choice between two 
> group definitions. The names of the elements are the same in 
> both groups 
> but their types are different. One could treat the group as a 
> whole as 
> one part or differentiate its subcomponensts, i.e. elements, 
> as parts. 
> Even this is done, the components within each group must be uniquely 
> identifiable as there are name and type collusions within 
> this schema. 
> How do we deal  with xs:choice in mapping rules? Please give some 
> examples for this schema and rules for generating parts.
> 
> (c). (recurringgroup.xsd) This is my rather poor attempt to write a 
> recursive schema by using a model group embedded within the 
> other with 
>  repeating elements names and type defns that can be defined in 
> arbitrary order. How would this schema mapped to "parts"? One 
> choice may 
> be to treat that recurring embedded group as one part (as an 
> array of a 
> group), but this means that constructs other than 
> elements/types must be 
> mappable to parts. (This particular approach is in fact taken by a 
> language binding for XML that I know of). What other choices 
> we have for 
> mapping? How do we deal with "xs:all"? Further, how can we treat 
> "test:letter" elements as an attachments? How can we treat the last 
> element in complexType "test:embeddedExample" as an attachment?
> 
> These are some questions that I came up with to create some 
> discussion. 
> Naturally, not all schemas would be suitable for RPC style 
> interaction. 
> However, if a generalization is to be made by using one 
> schema, then the 
> mapping rules, conventions and constraints considering the 
> full gory of 
> XML Schema must be explored. Further, this process should not require 
> someone to write a thesis to prove that a sound and complete 
> mapping for 
> RPC exists in the binding :-)
>  
> 
> --umit
> 
> References:
> 
> [1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0108.html
> [2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0066.html
> [3] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0067.html
> 
> -- 
> 
> Umit Yalcinalp					
> Consulting Member of Technical Staff            400 Oracle Parkway
> Oracle
> Phone: +1 650 607 6154                          Redwood Shores,
> Email: umit.yalcinalp@oracle.com                CA 94065, USA
> 
> 
> 
> 
> 
> 
> 
>

Received on Monday, 3 February 2003 22:07:48 UTC