W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > June 2009

[Issue-6413] Summary of what I heard and straw man proposal

From: Bob Freund <bob.freund@hitachisoftware.com>
Date: Tue, 30 Jun 2009 15:25:37 -0400
Message-Id: <D1614F9A-4300-497E-B70E-F229B84D7E12@hitachisoftware.com>
To: public-ws-resource-access@w3.org
Several have argued for inclusion of frag support within WS-T
Others have argued against it.
Issues as I hear them:

1. Composability.
It is probably better (in my opinion) of doing nothing that would  
hinder alternative frag support mechanisms in WS-T
In this regard, a proposal that gave frag support an independent  
namespace and used traditional composition mechanisms would make it  
clear.

2. Defining a clear direction.
Inclusion of frag support in T does establish a clear direction.  It  
is argued that it is more clear to be contained within the WS-T spec  
(and namespace?)

3. Adoption.
This is a bit unclear. Certainly a good frag spec would encourage  
adoption.  If composability with alternative frag support specs were  
discouraged, on the other hand, then adoption of WS-T might be reduced.
There is one known implementation of frag support in another spec,  
that is the version defined in WS-Man.  It currently exists by  
composing with an underlying WS-T.
it is not clear to me that including this frag proposal in WS-T would  
encourage or discourage them from using their own.  They are an  
independent minded group.

Proposal: (a bit of a cuisinart approach to be sure)
1. Include the frag support spec within WS-T
2. Compose it with traditional mechanisms
3. Give it its own namespace


Does this cut the baby in half well enough?
thanks
-bob


  

Received on Tuesday, 30 June 2009 19:26:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:18:04 GMT