RE: Plan for TAG issue 41

Bryan,

I've been thinking *a lot* about "server-side" resource identifiers.
I've been trying to figure out how we could RESTfully manipulate
secondary resource identifiers for Web service applications.  Turns out
to be quite hard.  I posted an example of manipulating an Artist, using
Schema to describe the xml constraints, and trying to use some algorithm
for secondary resource identifier syntax that a client could use. [1].
I'd be interested in your thoughts on that.

The WSDL 2.0 documents have a syntax that allows the URI space to be
controlled statically or dynamically based upon a simple XML element
binding to query parameters.  I think this is a good start, but I also
think it's also a bit broken as designed.  It only maps a default
namespaced xml sequence content to URI space.  No attributes (like ID!),
no multiple namespaces, no qnames for element names.  I encourage you to
comment on the WSDL 2.0 specification, which should be going to Last
Call any time now.

I take two points out of your posting that I have missed (and darn it, I
should have gotten them!):

- the relationship between versioning, formats, and identifiers.  If
there is any kind of coupling between the format and an identifier,
there is a versioning aspect to consider
- The use of alternate representations might not be in a single format
instance.  I've used the xslt example, and HTTP is another.  I'm worried
about getting into the a potential swamp of "resource" versioning
instead of just format versioning, but it seems unavoidable.

Cheers,
Dave

[1]
http://www.pacificspirit.com/Authoring/wsdl/ArtistWSDL2uriformencoding.h
tml


> -----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 13:27:26 UTC