Re: Rationale for Dropping the <soap:body use=...> Attribute

Authur, thanks for the illustration.

I'm not sure if the use of <key> <keyref> can constrain the Schema 
Type.  In your example, all you are saying is ...
1) Within the xpath "employee", the attribute "name" is unique and 
non-null.  Define this as a key.
2) Within the xpath "employee", the attribute "manager" must have a value 
that matches the above key.

You are NOT saying ....
-  The attribute "manager" must refer to an element whose type is "Employee"

In other words, the <unique> <key> <keyRef> is constrainting the "VALUE" 
that you can put in.  But it doesn't communicate any type information.

Also, the XPATH and type structure need to be synchronized manually.  There 
is NO way to enforce the consistence between them.  For example, if you 
modify the element type structure but forget to update the XPATH in the 
keys, you may have strange behavior.

Best regards,
Ricky

At 02:52 PM 9/18/2002 -0400, ryman@ca.ibm.com wrote:

>Ricky,
>
>ID and IDREF are defined in DTDs and are carried forward into XML Schema
>with much more flexibility. There are facilities in XML schema for
>validating references. You can use the <key>, <keyref> and <unique>
>elements. If you wanted to type check the references in an encoded graph
>you could add elements to the schema to express the type safety rules. (I
>actually did this on a development project).
>
>For example, suppose you had <employee> elements, and each employee had a
>unique name given by a name attribute, and optionally  refered to another
>employee that was their manager via a manager element, e.g.
>
><employee name="Arthur" manager="Hayden"/>
><employee name="Hayden" manager="Lee"/>
><employee name="Lee"/>
>
>The constraints are:
>1. employees are uniquely identified by their names
>2. the manager of an employee is another employee
>
>The following schema fragment implements the constraints:
>
><unique name="uniqueNames">
>   <selector xpath="employee"/>
>   <field xpath="@name"/>
></unique>
>
><key name="employeeNames">
>   <selector xpath="employee"/>
>   <field xpath="@names"/>
></key>
>
><keyref name="managerNames" refer="employeeNames">
>   <selector xpath="employees"/>
>   <field xpath="@manager"/>
></keyref>
>
>However, your other point that a SOAP encoded message cannot be validated
>against the schema in the WSDL is true in practice, but not for the above
>reason. The reason is that element content can be placed either inline or
>in a global element that gets refered to. The SOAP encoding algorithm does
>not specify how to generate a schema, just an instance. There is no reason
>why a smart tool couldn't generate an acurate schema (although it would be
>very ugly) to accurately represent a SOAP encoding message (XML Schema is
>pretty flexible). An equally smart tool could recognize the SOAP encoding
>pattern in the generated schema and generate the matching data structure.
>
>Arthur Ryman
>
>
>
> 
>
>                       Ricky 
> Ho 
>
>                       <riho@cisco.com>         To:       Arthur 
> Ryman/Toronto/IBM@IBMCA, Jacek Kopecky 
> <jacek@systinet.com>
>                       Sent by:                 cc:       WS Description 
> WG <www-ws-desc@w3.org>
>                       www-ws-desc-reque        Subject:  Re: Rationale 
> for Dropping the <soap:body use=...> Attribute
>                       st@w3.org 
 >
> 
>
> 
>
>                       09/18/2002 
> 01:49 
>
>                       PM 
 >
> 
>
> 
>
>
>
>
>
>Representing "graph" using XML Schema via the ID and IDREF is very very
>limited.  Today, you cannot specify an IDREF that reference a certain
>schema type.  (in other words, the IDREF is typeless so schema validation
>cannot traverse across an IDREF).
>
>This create a challenge for validating messages with SOAP encoding because
>a complex object are typically referenced by an IDREF.  In other words, the
>
>SOAP message format (using SOAP encoding) on the wire is not compliant with
>
>what is defined in the WSDL.
>
>Best regards,
>Ricky

Received on Wednesday, 18 September 2002 17:22:10 UTC