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