W3C home > Mailing lists > Public > www-tag@w3.org > July 2004

Plan for TAG issue 41

From: David Orchard <dorchard@bea.com>
Date: Thu, 29 Jul 2004 16:30:56 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF093E9E95@ussjex01.amer.bea.com>
To: <www-tag@w3.org>
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

 

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

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

 

Cheers,

Dave

 

 
Received on Thursday, 29 July 2004 21:51:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:26 GMT