W3C home > Mailing lists > Public > www-ws-desc@w3.org > February 2004

RE: Version attribute for WSDL

From: David Orchard <dorchard@bea.com>
Date: Fri, 13 Feb 2004 12:12:48 -0800
To: <paul.downey@bt.com>, <tomj@macromedia.com>, <www-ws-desc@w3.org>
Message-ID: <01c701c3f26d$c0162660$6501a8c0@beasys.com>
Ah Paul,

I had earlier thought about using URIs for the "minor" version # and the
problem of multiple nested versions and you are probably right about the
problem of increasing minor versions.  

Tell me though, is 3.3 compatible with 3.2.1.1?  I would assume they would
have to be.

I wonder if we could play some magic trick and say that the minor version is
a relative URI from the namespace name, and then the "match" could be of the
strings.  A nice use of URIs for comparison imo.

Dave

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of paul.downey@bt.com
> Sent: Friday, February 13, 2004 10:02 AM
> To: dorchard@bea.com; tomj@macromedia.com; www-ws-desc@w3.org
> Subject: RE: Version attribute for WSDL
> 
> 
> 
> I like this too, especially the defaulting on extension.
> 
> My small concern is using the integer to indicate the relationship
> between versions precludes branches, unless we allowed a SCCS/RCS/CVS 
> style numbering system, e.g:
> 
> 1 -> 2 -> 3 -> 4 -> 5 
>           |
>           +-> 3.1 -> 3.2 -> 3.3 
>                      |
>                      +-> 3.2.1
>                          |
>                          +-> 3.2.1.1 
> 
> i imagined the proper W3C way would be to use a URI for the 
> version and 
> relate them using syllogisms ?
> 
> Paul
> 
> 
> 
> 
> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of David Orchard
> Sent: 13 February 2004 17:47
> To: 'Tom Jordahl'; www-ws-desc@w3.org
> Subject: RE: Version attribute for WSDL
> 
> 
> 
> I like this as a strawman.  And the idea of not inheriting the version
> attribute makes a certain sense too, as it requires the 
> "extender" to make a
> conscious decision.  Though defaulting to "1" does have the 
> problem that the
> extender might not be compatible.  If there were some way in 
> the "extension"
> of knowing that the extensions could be ignored, then "1" makes sense.
> 
> cheers,
> Dave
> 
> > -----Original Message-----
> > From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org]On
> > Behalf Of Tom Jordahl
> > Sent: Friday, February 13, 2004 7:06 AM
> > To: 'www-ws-desc@w3.org'
> > Subject: RE: Version attribute for WSDL
> >
> >
> >
> >
> > I guess I understand the desire to have "real" versioning
> > support in WSDL
> > 2.0.  I do too. But my proposal came out of the F2F, where we
> > had a long,
> > and I believe fruitless, discussion about all of this.
> >
> > I do not believe we can have a section in our specification
> > about versioning
> > and say "if you want versioning, change the namespace".  
> With a small
> > addition to the syntax, we can give users some help in
> > managing change in
> > their web services.
> >
> > I am willing to apply semantics to the version attribute if 
> this group
> > thinks that they can move forward in a productive way.  How
> > about these
> > changes as a straw man for discussion:
> >
> >  - The version attribute is part of the infoset (a.k.a. the
> > component model)
> >
> >  - The version attribute has type xsd:positiveInteger
> >
> >  - The version attribute has a default value of 1.
> >
> >  - The version attribute indicates a "minor" revision of the
> > definition or
> >    interface. Specifically, a "minor" revision indicates that
> > a client using
> >    a WSDL with a version attribute less-than the current
> > value is expected
> >    to continue to function.
> >
> >  - When an interface extends another interface, the version
> > attribute of the
> >    interface is NOT inherited - it must be explicitly set on
> > the interface,
> >    and if is not, the interface has the default version 
> attribute (1).
> >
> > Example 1: Version 1 of my interface has two operations. I
> > release a new
> > WSDL that adds a third operation, and change the version
> > attribute to 2.
> > Clients who are using the previous version of the WSDL
> > continue to function.
> >
> > Example 2: My WSDL has a purchase order type defined and a
> > target namespace
> > of "http://example.org/myservice".  I change my purchase
> > order to include
> > several new elements and rename some of the old ones.  Since
> > this change
> > will break compatibility, I change the target namespace to
> > "http://example.org/myservice/v2".  My service can now 
> easily tell the
> > difference between clients that are using the original WSDL
> > and the new one.
> >
> >
> > --
> > Tom Jordahl
> > Macromedia Server Development
> >
> > -----Original Message-----
> > From: Jeff Mischkinsky [mailto:jeff.mischkinsky@oracle.com]
> > Sent: Friday, February 13, 2004 2:56 AM
> > To: Tom Jordahl; 'www-ws-desc@w3.org'
> > Subject: RE: Version attribute for WSDL
> >
> > At 12:41 PM 2/12/2004, Tom Jordahl wrote:
> >
> >
> > >David,
> > >
> > >We wouldn't say anything like this about the version attribute.
> > >      "..it has no semantics.."
> > >
> > >So David can tell his WSDL consumers that he uses this attribute to
> > indicate
> > >compatible versions of the same WSDL file.  And I can tell
> > my users that
> > >version 1 does not equal version 2.  But as WSDL spec
> > authors we don't have
> > >to take a stand on how this is done.
> > >
> > >Isn't that nice?  We don't have to fight about what it means.
> >
> > and the point of "standardizing" this would be?
> > (in this case I'm using the word standardize in its loosest most
> > meaningless sense :-)
> >
> > jeff
> >
> >
> > >--
> > >Tom Jordahl
> > >Macromedia Server Development
> > >
> > >-----Original Message-----
> > >From: David Orchard [mailto:dorchard@bea.com]
> > >Sent: Thursday, February 12, 2004 2:32 PM
> > >To: paul.downey@bt.com; vbp@hp.com; tomj@macromedia.com;
> > www-ws-desc@w3.org
> > >Subject: RE: Version attribute for WSDL
> > >
> > >I'm interested in the version attribute for identifying
> > versions within
> > >"compatible" definitions.  I would like to have our spec say
> > explicitly
> > >that.  I am strongly strongly opposed to using a version
> > attribute for
> > >identifying different incompatible versions.  That's what
> > namespaces and
> > >URIs are for.
> > >
> > >Some off-the-cuff suggestions for the wording:
> > >
> > >"The version attribute identifies a particular version of
> > the definitions,
> > >that is compatible with all other versions with the same
> > targetnamespace.
> > >It SHOULD not be used to identify incompatible definition 
> versions."
> > >
> > >Cheers,
> > >Dave
> > >
> > > > -----Original Message-----
> > > > From: www-ws-desc-request@w3.org
> > [mailto:www-ws-desc-request@w3.org]On
> > > > Behalf Of paul.downey@bt.com
> > > > Sent: Thursday, February 12, 2004 9:02 AM
> > > > To: vbp@hp.com; tomj@macromedia.com; www-ws-desc@w3.org
> > > > Subject: RE: Version attribute for WSDL
> > > >
> > > >
> > > >
> > > > I believe the version value is useful information for when the
> > > > interface has been compatibly changed within the same namespace.
> > > >
> > > > +1 Tom's proposal, i can't see any harm and it could be useful
> > > > as a building block for a mechanism for relating an interface
> > > > version to other versions, akin to the 'previous', 'this' and
> > > > 'latest' version URLs on W3C publications.
> > > >
> > > > Paul
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: www-ws-desc-request@w3.org
> > [mailto:www-ws-desc-request@w3.org]On
> > > > Behalf Of Vambenepe, William N
> > > > Sent: 12 February 2004 16:53
> > > > To: Tom Jordahl; www-ws-desc@w3.org
> > > > Subject: RE: Version attribute for WSDL
> > > >
> > > >
> > > >
> > > >
> > > > Thanks Tom for the proposal. I could live with this attribute on
> > > > <definitions> but I really don't like it on <interface>. As Glen
> > > > eloquently explained at the F2F, a different interface
> > should use a
> > > > different QName. What does it mean for a binding to reference an
> > > > interface if there are dozens of "versions" of this
> > interface. Can I
> > > > have a binding for only a certain version of an
> > interface? I know we
> > > > don't have to answer this since we "define no semantic" but
> > > > that doesn't
> > > > make the problem go away.
> > > >
> > > > William
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: www-ws-desc-request@w3.org
> > > > > [mailto:www-ws-desc-request@w3.org] On Behalf Of Tom Jordahl
> > > > > Sent: Thursday, February 12, 2004 6:13 AM
> > > > > To: 'www-ws-desc@w3.org'
> > > > > Subject: Version attribute for WSDL
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > In fulfillment of my action item received at the January F2F,
> > > > > here is a
> > > > > proposal to add a version attribute to WSDL to aid in the
> > > > > versioning of WSDL
> > > > > documents and interfaces.
> > > > >
> > > > > I propose that an attribute with the name "version" be
> > added to the
> > > > > <definitions> element of WSDL.  This attribute is for user
> > > > > convenience, and
> > > > > the specification would define no semantics for it,
> > > > > specifically the value
> > > > > of this attribute would NOT be included in the infoset.
> > > > > However, it is
> > > > > expected that WSDL authors and consumers can use this
> > > > attribute, when
> > > > > present, to differentiate between different revisions of a
> > > > > WSDL document.
> > > > >
> > > > > Example:
> > > > >
> > > > > <definitions version="1" targetNamespace=http://sample.org/>
> > > > > ...
> > > > > </definitions>
> > > > >
> > > > > This proposal is modeled after the version attribute of XML
> > > > > Schema, see
> > > > > section 3.15.2 in Part 1 of the XML Schema specification:
> > > > >   http://www.w3.org/TR/xmlschema-1/#Schemas
> > > > >
> > > > > In our specification, section 2.1.2 would be updated to
> > > > > include the new
> > > > > attribute:
> > > > >
> > > > > 2.1.2 XML Representation of Definitions Component
> > > > >
> > > > > <definitions
> > > > >       targetNamespace="xs:anyURI"
> > > > >       version = "xs:token"? >
> > > > >   <documentation />?
> > > > >   [ <import /> | <include /> ]*
> > > > >   <types />?
> > > > >   [ <interface /> | <binding /> | <service /> ]*
> > > > > </definitions>
> > > > >
> > > > >
> > > > > Additionally, I propose that a similar version attribute be
> > > > > added to the
> > > > > <interface> element of WSDL. This attribute would mirror the
> > > > > definitions
> > > > > attribute.  Again, this would be for user convenience, and
> > > > > the specification
> > > > > would define no semantics for it, specifically the value of
> > > > > this attribute
> > > > > would NOT be included in the infoset.  WSDL authors and
> > > > > consumers could use
> > > > > this attribute, when present, to differentiate between
> > > > > different revisions
> > > > > of an interface.  In particular, this would enable a
> > consumer of the
> > > > > document to know explicitly when an interface they are using
> > > > > has changed.
> > > > >
> > > > > Example:
> > > > > <definitions>
> > > > >   <interface name="myInterface" version="alpha17">
> > > > >     ...
> > > > >   </interface>
> > > > > </definitions>
> > > > >
> > > > >
> > > > > 2.2.2 XML Representation of Interface Component
> > > > > <definitions>
> > > > >   <interface
> > > > >         name="xs:NCName"
> > > > >         extends="list of xs:QName"?
> > > > >         styleDefault="xs:anyURI"?
> > > > >         version = "xs:token"? >
> > > > >     <documentation />?
> > > > >     [ <operation /> | <feature /> | <property /> ]*
> > > > >   </interface>
> > > > > </definitions>
> > > > >
> > > > >
> > > > > --
> > > > > Tom Jordahl
> > > > > Macromedia Server Development
> > > > >
> > > > >
> > > >
> > > >
> >
> > Jeff Mischkinsky                      jeff.mischkinsky@oracle.com
> > Consulting Member Technical Staff     +1(650)506-1975
> > Director, Web Services Standards      500 Oracle Parkway M/S 4OP9
> > Oracle Corporation                    Redwood Shores, CA 94065
> >
> >
> 
> 


Received on Friday, 13 February 2004 15:12:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:02 UTC