RE: Plan for TAG issue 41

Agreed. I covered this topic somewhat in the updated version of my
article at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnexxml
/html/xml07212004.asp in the section entitled 'Message Transfer
Negotiation vs. Versioning Message Payloads' 

Putting versioning constructs in the XML payload is just one approach
for determining compatibility between two parties exchanging data using
an XML format. 

--  
PITHY WORDS OF WISDOM
A day off is usually followed by an off day.  

This posting is provided "AS IS" with no warranties, and confers no
rights.


-----Original Message-----
From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf
Of Thompson, Bryan B.
Sent: Friday, July 30, 2004 6:52 AM
To: 'David Orchard '; 'www-tag-request@w3.org '; 'www-tag@w3.org '
Cc: Bebee, Bradley R.
Subject: RE: Plan for TAG issue 41


David,

It occurs to me that some of the things that I've been working on
recently are relevant to the discussion of versioning.  I've been
working with XPointer and the HTTP Range header to get "server-side"
XPointer processing, which is not relevant in itself, but it has led to
considering the client-server interaction lock-in that results when the
XPointer scheme makes use of the XML data model -- this was actually
pointed out on this list some months ago by Roy Fielding [1][2].

For example, if you declare an XPointer scheme that tunnels the XPath
Recommendation, then you are identifying sub-resources based on the XML
data model (something that a lot of people are doing without the
costs/benefits of the XPointer framework).  This means that their
sub-resource identifiers can break if the schema governing their XML
documents changes - and will break if they change to a non-XML data
model, which could be seen as a more extreme / less-constrained case of
versioning.

So, my point is that there are protocol level ways to handle versioning
outside of standards or best practices for managing the evolution of an
XML schema or a web services interface and that the choices that you
make with identifiers (URIs) have an impact on your ability to evolve/
version representations.

You did mention protocol extensibility below, but I'm not sure if you
are thinking of things like HTTP Content Negotiation and Redirects as
mechanisms for versioning.

[1] http://lists.w3.org/Archives/Public/www-tag/2004Feb/0075.html
[2] http://lists.w3.org/Archives/Public/www-tag/2004Apr/0019.html

Thanks,

-bryan

-----Original Message-----
From: www-tag-request@w3.org
To: www-tag@w3.org
Sent: 7/29/2004 9:52 PM
Subject: Plan for TAG issue 41

Over the past half year, I've been executing on a rough mental plan for
the next version of the TAG finding on issue 41.  I've been steadily
creating material for inclusion in the finding.  I've run the plan by
Norm and he agrees with it.  The plan, including references, is listed
below.

 

Overall

The options and trade-offs for versioning are not clearly enough
articulated.  For example, the problems of using a new namespace for any
additional version information are not clear enough.  Design for
transformation of vX data into vY data (substitutability) has a number
of options that need to be listed and described.  An examination of
protocol extensibility, that is the addition/deletion of operations, and
compatibility of groups of operations (interfaces) provides for
versioning and extensibility beyond just formats. 

 

I'd like to take the xml schema example that was in the first draft of
the finding and move it, as well as providing for various languages -
XML Schema, RelaxNG, and RDF/OWL - into an "Extensibility and versioning
using various languages" document.  Dare Obasanjo's delimiter technique
should be added to this doc.   And finally, the issue of versioning of
interfaces using WSDL will be introduced.

 

Details:

 

In all documents:

-          change examples to "name" example - first,last and add a
middle

 

Into Tag finding

-          More discussion on extensibility versus versioning, some text
towards end of
http://www.pacificspirit.com/Authoring/Compatibility/ProvidingCompatible
SchemaEvolution.html

-          Expand and list trade-offs of: no namespace evolution (ie
xslt), re-using namespace, and new namespace for new components in
language when versioning.  Summarize choices author must make, ie "#1.
choose 1 of (single ns forever, evolvable ns, multiple ns) for
versioning.  Choose 1 of (evolve schema in backwards compatible way,
don't evolve schema, don't do backwards compatible evolution) when
versioning.

-          Move towards and add text on "substitutability must be in
V1.0",
http://www.pacificspirit.com/blog/2004/05/26/substitution_rules_must_be_
in_v10.

-          Add material on various substitution rules, ranging from
static (must ignore) to dynamic (xslt?),
http://www.pacificspirit.com/blog/2004/06/14/whither_substitution_rules

-          add protocol extensibility,
http://www.pacificspirit.com/blog/2004/06/14/protocol_extensibility_and_
versioning

-          Add material on issue about service compatibility (related to
protocol extensibility),
http://www.pacificspirit.com/blog/2004/06/29/interface_compatibility_v2
<http://www.pacificspirit.com/blog/2004/06/29/interface_compatibility_v2
> 

 

Create "Extensibility and versioning using various languages" document

-          insert original xml schema material

-          Optionally add Henry's 2pass schema example (allows for
default extensibility).

-          add relax ng example

-          add rdf/owl example, I have one in progress (@@) and there is
some discussion on atom.

-          Add delimiter technique,
http://www.xml.com/pub/a/2004/07/21/design.html

-          WSDL example for service extensibility (ie WSDL does not
guarantee service compatibility),
http://www.pacificspirit.com/blog/2004/06/29/using_wsdl_schema_for_compa
tible_evolution
<http://www.pacificspirit.com/blog/2004/06/29/using_wsdl_schema_for_comp
atible_evolution> 

-          Issues of leaky abstraction of schema language choice(s) into
types, particularly extensibility models.

 

Cheers,

Dave

Received on Friday, 30 July 2004 17:31:38 UTC