Re: Comments on WSDL 1.1 Element Identifiers

Amy,

The WSDL 1.1 <import> is modelled on XSD <import> so you don't use it to 
import the same namespace. The example 2 in the spec [1] shows splitting a 
document into two different namespaces.

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

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



"Amelia A. Lewis" <alewis@tibco.com> 
Sent by: www-ws-desc-request@w3.org
02/13/2007 04:21 PM

To
Jonathan Marsh <jonathan@wso2.com>
cc
www-ws-desc@w3.org
Subject
Re: Comments on WSDL 1.1 Element Identifiers







One comment:

Jonathan Marsh wrote:
> 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.

Err, I don't believe that this is the case.

Specifically, it is possible (and in fact an example is given in the 
WSDL 1.1 specification) to "partition" a WSDL into pieces, all of which 
have the same namespace.  In other words, a WSDL 1.1 document can import 
another WSDL 1.1 document that has the same namespace as the importing 
document, and the practice is more or less recommended in the WSDL 1.1 
specification as a means of modularizing definitions.

WSDL 1.1 does not, as I understand it, specify behavior in cases in 
which an import redefines an existing definition, if those definitions 
differ.

Consequently, while it may be possible to create ambiguous pointers due 
to the multi-purpose import/include/dessert-wax nature of WSDL 1.1 
import, that ambiguity is going to reflect ambiguity within the set of 
documents.  Arguably, broken pointers are better suited for broken 
documents than working ones.  Right?  :-)

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com