RE: Comments on WSDL 1.1 Element Identifiers

I promised to look again at my analysis.

 

My claim that imports and includes make designating a WSDL element difficult
are false to because is no include in WSDL 1.1, and WSDL 1.1 imports require
a namespace.  There will thus be a 1-1 correspondence between a WSDL 1.1
document and a particular target namespace.

 

My claim that constructing a canonical identifier (as the spec recommends)
is true to the extent that WSDL 1.1 does not require a target namespace.  In
practice again this not likely to be considered good practice.

 

My claim that imports and includes make designating a Schema element
difficult are relevant because schema elements typically reside in a
separate namespace, parts of which may be imported or included using schema.
The primary case, where the entire schema, in a different namespace, is
imported, doesn't seem to be well specified.  I wonder why the list includes
them (other than blindly copying the WSDL 2.0 spec).

 

So I'd suggest our comments should include:

 

1)      The spec should at least note the situations which conflict with the
creation of an element identifier from the targetnamespace - namely, when
the WSDL document does not have a targetNamespace.

2)      The inclusion of identifiers for element declarations and type
definitions (which are not WSDL elements) seems inappropriate in this spec.
The presence of schema imports and includes makes associating type
definitions with a particular WSDL document, and with a particular
targetNamespace, problematic.  These identifiers don't seem to be required
by WS-Policy Attachment.  If these identifiers remain, the issues related to
them should be addressed:

a.      How imports and includes affect them.  Are only in-lined schema
elements considered?  If not, which ones?

b.      Clarification in the prose of the spec that WSDL element identifiers
identify elements both in the WSDL and Schema namespaces.

c.      The "types" vs. "type definitions" issue below (Arthur's).

 

Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com

 

  _____  

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Jonathan Marsh
Sent: Wednesday, February 07, 2007 12:02 PM
To: 'Arthur Ryman'; www-ws-desc@w3.org
Subject: RE: Comments on WSDL 1.1 Element Identifiers

 

I reread the document as well, and see a pretty large disconnect between the
statement "the fragment identifiers are to the WSDL 1.1 elements prior to
any processing of the WSDL document, such as validation, inclusion, imports,
schema type validation, etc." and the whole rationale for designing a
specialized element identification syntax.  Namely, it gives rise to the
following problems:

 

1)  Except in the case where there are no imports or includes, simply making
a WSDL 1.1 document available at the namespace URI is not sufficient to
enable identification of all the WSDL elements in that post-import,
post-include WSDL document through a namespace-based URI.

2)  Except in the case where there are no imports or includes, there cannot
be a canonical form, as there is no equivalent to the namespace URI defined
for imported and included documents.

 

A WSDL document, together with its imports and includes, defines a
namespace.  Identifying an element within that namespace definition involves
identifying which document it came from.  The WSDL 2.0 component designators
serve little purpose beyond what could be done with generic XPointers except
that they operate over an abstraction that covers imports and includes.
These WSDL 1.1 element identifiers don't have that motivating factor.

 

I would investigate either defining how includes and imports are to be
processed, so an identifier based on namespace URIs becomes workable,
dropping the sections on constructing a canonical namespace-based identifier
in favor of simply defining an application/xml xpointer scheme which users
can use to locate elements within their WSDL 1.1 resources, or best of all
to consider dropping this specialized syntax completely in favor of a
generic syntax for identifying elements within XML documents (e.g. the xpath
fragment scheme).

 

Also, "The pointer parts have a scheme name that corresponds to one of the
standard WSDL 1.1 element names, and scheme data that is a path composed of
names that identify the elements" doesn't seem true for Element Declaration
or Type Definition components, which aren't in the WSDL 1.1 namespace.  I
suspect there are lurking issues here about precisely which element
declarations and type definitions can actually be referred to - especially
when schema imports and includes come into play.

 

I'd like the WSDL WG to consider forwarding these comments, and Arthur's
below, to the WS-Policy WG.

 

Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com

 

  _____  

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Arthur Ryman
Sent: Thursday, February 01, 2007 8:52 AM
To: www-ws-desc@w3.org
Subject: Comments on WSDL 1.1 Element Identifiers

 


In fulfilment of my action item, I reviewed the spec again [1]. 

The only problem I see is the row for Type Definitions: 

Type Definition types QName n/a n/a wsdl11.types(types) 

I think there is confusion here between the wsdl:types element and
xs:complexType or xs:simpleType elements. 

There is no need to identify the wsdl:types element as a whole, although
they are free to do so. 

The intension of that row should have been to identify XSD types defined
within the wsdl:types element. These Type Definition elements are useful
because they are used in wsdl:message parts. 

The fix is: 

Column 1: type QName 
Column Pointer Part: wsdl11.typeDefinition(type) 

Example 3.4 should be modified to include the wsdl11.typeDefinition
identifiers. 

[1] http://www.w3.org/TR/wsdl11elementidentifiers/ 

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca