W3C home > Mailing lists > Public > www-ws-desc@w3.org > September 2002

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

From: Arthur Ryman <ryman@ca.ibm.com>
Date: Thu, 19 Sep 2002 09:11:05 -0400
Message-ID: <3D89CCE9.D75BC525@ca.ibm.com>
To: www-ws-desc@w3.org

Ricky,

Yes, I am saying that this schema does constrain @manager to refer to an <employee> element because
<keyref ref="employeeNames" ...> means that the @manager attribute has a value that is a member of the set
of keys named employeeNames, and <key name="employeeNames"> defines this set of keys to be the values of
the @name attribute of <employee> elements which are further constrained to be <unique>. Therefore @manager
only refers to <employee> elements.

In fact, XML Schema gives you more than simple type safety. It gives you "range" safety. In a programming
language you can only declare the type of a reference. You cannot further constrain the range of values of
that type. In XML Schema, you can constraint the values to a specified set using XPath. For example, you
could group the employees that are managers in a <managers> element and then use the xpath
managers/employee to select the keys, e.g.

<ants>
  <employee name="Arthur" manager="Hayden"/>
</ants>
<managers>
  <employee name="Hayden" manager="Lee"/>
  <employee name="Lee"/>
</managers>

<unique name="uniqueNames">
<selector xpath="employee"/>
<field xpath="@name"/>
</unique>

<key name="managerNames">
   <selector xpath="managers/employee"/>
   <field xpath="@names"/>
</key>

<keyref name="managerRefs" refer="managerNames">
   <selector xpath="employees"/>
   <field xpath="@manager"/>
</keyref>


I agree that the XML Schema to define these constraints is complex, and I do  not expect a developer to
manually create it. This example was used to show that you can encode object graphs in XML using ID and
IDREF in a type safe way. That means you start with a data type in some programming language and then
derive the XML Schema from it. I expect that tools would automate this task so manually maintaining the
schema is not a problem. If you modify the data type then you regenerate your schema.

>

>
> Message-Id: <4.3.2.7.2.20020918135515.043ec7f0@franklin.cisco.com>
> Date: Wed, 18 Sep 2002 14:21:26 -0700
> To: ryman@ca.ibm.com, www-ws-desc@w3.org
> From: Ricky Ho <riho@cisco.com>
> Subject: 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
Received on Thursday, 19 September 2002 09:11:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:21 GMT