- From: <ryman@ca.ibm.com>
- Date: Fri, 27 Sep 2002 17:03:36 -0400
- To: www-ws-desc@w3.org
Eric,
WSDL syntax is modelled on XSD in the sense that in XSD you can have a type
and an element that have the same name. What is the recommended solution
for XSD? Shouldn't WSDL follow that for simplicity?
Arthur Ryman,
"Eric
Prud'hommeaux" To: www-ws-desc@w3.org
<eric@w3.org> cc:
Sent by: Subject: Arguments for keeping R120
www-ws-desc-reque
st@w3.org
09/27/2002 02:17
PM
This message attempts to clarify some of the reasoning behind R120 in
the WSDL 1.2 requirements draft [1] which states:
[[
R120
The description language MUST ensure that all conceptual elements in the
description of Messages are addressable by a URI reference [IETF RFC 2396].
]]
Initially I wasn't sure what to say about this requirement, because I
view it as fundamental to what makes the Web work. But Philippe and I
discussed the issue yesterday and came up with the following
points/clarifications.
A large amount of deployed infrastructure uses URIs to identify useful
parts of the web. There will be a temptation to carry this tradition
into web services tools. For instance, it would be easy to invent
qname transformations that added the type to a portType's (q)name to
distinguish it from a message's (q)name and store the associated
element in a generic XML database for retrieval by another WSDL-aware
application later.
+-----------+ +---------------+
WSDL -> |WSDL parser| |WSDL processor | -> service request
+--------|--+ +--^------------+
V |
+--------------------+
|generic XML database|
+--------------------+
While it is feasible for the author of this WSDL parser/archiver to
transform the qnames into uris including the type, eg
http://example.org/ws#binding_CalcHttpPost
doing so asserts names into a namespace outside of one's
administrative control and is therefor not guaranteed not to collide
with other uses of the invented name.
Requiring the name of a service description fragment to be scoped to
the type of that element prevents future protocols from identifying
that element without the type. This may work for the conceivable
WSDL-aware applications but there are a host of more abstract
applications that could be used to enhance web services without having
to know the specific semantics of WSDL.
Trust/endorsement services could associate some principal's public
key with a URI and some machine readable assertions of trust. For
instance, one may use a SAML-like [2] language to state that a
particular set of services has been investigated may be used in an
orchestration, or that an endpoint is good for transactions up to
a certain limit.
Analogous assertions of digital rights may be made by languages like
XACML [3], XMCL [4] or ORDL [5].
Google-like search services may provide pointers to objects without
knowing their type. URL-backed elements are easy to research and use.
It would be possible to define WSDL component identifiers for each of
these protocols, but it is much easier when all that is needed is a
URI reference. It would also be possible to encode the qname and
namespace into a single URI safely:
targetNamespace="http://example.org/ws"
+ <binding name="CalcHttpPost" ... />
=> reserved base URL + URLencode(type + '!' + targetNamespace + '!' +
qname)
=>
http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0082.html#binding%21http%3A%2F%2Fexample.org%2Fws%21CalcHttpPost
but this subverts the intended association between a qname and the
namespace in which it is allocated.
XPath could provide a way to identify the XML elements to which the
semantics of a binding or portType or... are attached. This requires
the agents expected to opperate on these elements to have an XPath
impelementation, which is a heavy trade-off against the ease of
service description generation. Some XPaths would be resilient against
isomorphic variations in the WSDL:
http://example.org/something.wsdl#/definitions[@targetNamespace="
http://example.org/ws"]/binding[@name="CalcHttpGet"]
but others will be less resilient:
http://example.org/something.wsdl#/definitions/binding[2]
Using XPath also hides the identifying pair of targetNameSpace and
element name. WSDL-aware applications will tend to identify the above
binding with the tuple binding|http://example.org/ws|CalcHttpGet. For
instance, when the application tells the user to pick a binding, the
user will pick the http://example.org/ws namespace and the CalcHttpGet
binding within it. The XPath, however, will be referenced via some
instance of a service description that references that
element. Generic XML tools will not be able to associate it with
another element in another WSDL document that references exactly the
same binding:
uid:154534234#/definitions[@targetNamespace="http://example.org/ws
"]/binding[@name="CalcHttpGet"]
Some current implementations, at least Axis, already attach the type
to the generated name:
<message name="GetAddressFromNameRequest" ... />
<binding name="AddressBookSOAPBinding" type="tns:AddressBook" ... />
<service name="AddressBookService" ... />
Code generators have no more work to do to generate document-wide
unique names than they do to generate element-type-specific unique
names. Perhaps even a little less. This also applies to validating the
uniqueness of the names.
In summary: The debate over R120 stems from a tension between putting
identification requirements on users and the benfits of these
requirements to the protocols and infrastructure. WSDL-specific
applications have the ability to address choice elements by context
within the protocol that defines exactly what type, and therefore
scope, to expect. Merging these scopes marginally increases the burden
on the hand-generated WSDL craftsman while making these elements
addressable by a host of convievable and not yet concieved
applications built on lower level XML infrastructure.
[1]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/requirements/ws-desc-reqs.html#semanweb
[2 SAML] http://www.oasis-open.org/committees/security/
[3 XACML] http://xml.coverpages.org/xacml.html
[4 XMCL] http://www.w3.org/TR/xmcl/
[5 ORDL] http://www.w3.org/TR/odrl/
--
-eric
office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell: +1.857.222.5741
(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.
Received on Friday, 27 September 2002 17:08:24 UTC