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