RE: Action 2003-01-21 for Umit

Umit,

I have struggled greatly with your assertion that whatever replaces
message must be able to map into the part concept

More comments inline.

Gudge

> -----Original Message-----
> From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com] 
> Sent: 04 February 2003 00:08
> 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. 

I don't understand this. My thought was that we would define schema
types/element, schema provides for cardinality/disjunction, which in
turn provides for variations on the wire. 

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

I don't understand why I would want to do this.

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

Again, I don't understand why we need the notion of 'parts'. 

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

I don't understand why you would want to go that way unless we want to
allow people to transform WSDL 1.2 into WSDL 1.1, which I think is a
non-goal.

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

Why wouldn't the binding just say the XML on the wire must match the
background-record element ( or the backgroundType type ). If you really
wanted to be able to bind a subset of that type, I would say derive a
type by restriction that describes the subset you want and then bind
that.

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

I still don't understand what you mean by parts. Schema describes
Infosets using types. Those types are refed from an operation. I don't
really see why the binding needs to say anything except "we're doing
SOAP, so put that stuff in the Body' or 'we're doing some message
queueing, serialize that type into this property'

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

I don't understand what 'operation signatures' means. Whenever there is
cardinality or disjunction there are multiple possible valid XML
serializations.

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

I'd naturally define three GEDs and ref those from the operations in the
port type.

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

As I stated somewhere above, I'm not convinced that there NEEDS to be
complexity at the binding level. We could ALLOW complexity at the
binding level but I don't think it HAS to be complex.

> We need the message/part abstraction in the 
> abstract level as 
> well.

I think this is the crux of where we disagree.

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

I think anything which is of type xsd:base64Binary or xsd:hexBinary can
be serialized as an attachment. The binding would specify such a
serialization for a given element using either a SCD or an XPath.

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

This schema is not legal. You cannot have multiple elements with the
same {namespace name, local name} pair but different types.

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

I don't understand what you mean by mapping rules. At the binding level
we just say 'serialize that type ( or element )'.

> 
> (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"? 

Again, I don't understand why I would want to 'map' the schema 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"? 

What's difficult about 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. 

As I have stated on numerous occasions, I do not think RPC is a WSDL
level issue. That said, I can provide method signatures for the examples
you gave if you like.

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

Did you mean 'glory of XML Schema'? ;-)

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

I don't understand what you mean by 'a mapping to RPC exists in the
binding'. To me a binding describes concretely what the serialized
message looks like. And then provides details of how to tranport that
message from A to B. Bindings should not mandate anything about
programming model.

Gudge

Received on Thursday, 27 February 2003 08:10:18 UTC