Re: Issue 6413 - Merge WST/T : Proposal

Hi Geoff:
I came upon this independently of Doug and Katy. When I laid the WS-T 
ans WS-RT specs on top of
each other, there was a very good match except for what may appear in 
the body. So, a simplified semantic
may go:
- If there is a fragment identifier in the body, the verb applies to the 
fragment.
- If not, the verb applies to the entire representation.

I think this is simpler because it coalesces 2 very similar specs into one.

All the best, Ashok


Geoff Bullen wrote:
>
> Katy, Doug,
>
> As well as understanding the reasoning behind wanting to make this 
> change, and the value it may or may not provide, it is also important 
> to understand the potential negative impact this merger may have:
>
> 1) There is clearly a substantial need for a simple Transfer spec. 
> This is shown by the number of other specs that have taken a 
> dependency on Transfer and also by the number of implementations that 
> are already out there. The same need cannot be shown for RT. Merging a 
> spec of limited value with a spec of great value does not make 
> architectural sense. Normally you would keep this kind of 
> functionality separate so that only those (few) people who need the 
> extra (less valued) functionality are forced to deal with it.
>
> 2) There has already been significant interop performed on Transfer. 
> We are not aware of any for RT. Merging the two would significantly 
> increase interop requirements for Transfer. Re-reading the minutes 
> from the first F2F, no one, except IBM was interested in RT (and 
> therefore RT interop).
>
> 3) Joining the specs together will make any profile (and potentially 
> dependent spec) that uses Transfer much more difficult to define, 
> causing significant additions to be made in order to achieve what they 
> already have at present, by default.
>
> 4) We are already concerned with some of the architectural 
> implications of the current RT spec (e.g. so called box-carring) and 
> we do not wish to see these issues exacerbated by adding them to a 
> currently easy to explain and implement specification.
>
> Cheers,
>
> Geoff
>
> *From:* public-ws-resource-access-request@w3.org 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Geoff 
> Bullen
> *Sent:* Thursday, March 05, 2009 11:33 AM
> *To:* Katy Warr; public-ws-resource-access@w3.org
> *Cc:* dug@us.ibm.com
> *Subject:* RE: Issue 6413 - Merge WST/T : Proposal
>
> Katy,
>
> What is the justification for adding all this complexity and making 
> all these changes?
>
> If you have technical issues with T and RT, (Issue 6413 talks about the need to “reduce the complexity” – what complexity?) then it would be good to get those issues out on table, so we can address them. 
>
> Cheers,
>
> Geoff
>
> *From:* public-ws-resource-access-request@w3.org 
> [mailto:public-ws-resource-access-request@w3.org] *On Behalf Of *Katy Warr
> *Sent:* Thursday, March 05, 2009 9:50 AM
> *To:* public-ws-resource-access@w3.org
> *Cc:* dug@us.ibm.com
> *Subject:* Issue 6413 - Merge WST/T : Proposal
>
>
> Doug and I propose the following to resolve issue 
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6413.
> Thanks
> Katy
>
> GENERAL COMMENTS (Applying to the complete document)
> ----------------------------------------------------
>
> - This proposal takes the WS-Transfer specification as a base for the 
> merge of the two specs (i.e. copy WS-RT into WS-T with minimum change 
> to existing WS-T text).
>
> - Replace all existences of wsrt namespace/prefix with wst 
> namespace/prefix.
>
> - Stylistic differences - bring wsrt in line with wst.
> For example:
> [Body]/wsrt:Get/wsrt:Expression
> becomes
> /s:Envelope/s:Body/wst:Get/wst:Expression
>
>
> Resource/Factory operation Sections
> -----------------------------------
>
> - The key aspect of this proposal is the merging of the 
> Resource/Factory operations. The pattern for merging these operations 
> is likely to be the same so we've started by taking "Get" as an 
> example. Details for the other operations will follow.
>
> Proposal for "Get" operation:
>
>
>
>
> Introduction and Terminology and Notation Sections
> --------------------------------------------------
>
> - Introduction
> After the following text in WST introduction:
> "Specifically, it defines two operations for sending and receiving the
> representation of a given resource and two operations for creating and
> deleting a resource and its corresponding representation."
> Add the following (this is taken from WSRT with modification):
> "This specification also defines optional extensions in order to deal 
> with fragment-based access to resources."
>
> - Add WSRT requirements to those listed in WST that are generic and 
> not management specific* *
>
> - Add WSRT non-requirements section to WST
>
> - WSRT Example
> The example in the introductory section is useful but would detract 
> from the core usage scenario of WS-T if it was copied to the WS-T 
> introduction.
> Proposal: Move this example to an appendix in WS-T entitled "Example 
> Resource Fragment Get". Raise an issue to integrate examples into the 
> main text when it merge is stablised.
>
> - Terminology: Resource
> Text for the 2 specs differs and requires reconciliation. Here are the 
> current texts for discussion in WG.
> WST:
> A Web service that is addressable by an endpoint reference as defined
> in WS-Addressing and that can be represented by an XML Infoset using
> the Get and Put operations defined in this specification.
> WSRT:
> A Web service that is addressable by an endpoint reference as defined 
> in WS-Addressing and that can be represented by an XML document. This 
> representation can be accessed using the operations defined in the 
> WS-Transfer and WS-ResourceTransfer specifications.
> Proposal: use the text in wst
>
> - Terminology: WSRT Resource representation, Metadata resource, 
> fragment, epr
> Add these definitions to wst spec.
>
> - XML Namespaces:
> Add ws-mex namespace to list in WST.
>
> - Compliance
> Proposal - leave compliance section as is. Ensure wsrt aspects of spec 
> are clearly defined as optional in the main text.
>
> Section 4 "Extensions to WS-Transfer" section in WS-RT
> ------------------------------------------------------
>
> - Add a new section prior to section 3 "Resource Operations" in 
> WS-Transfer called "Support for Resource Fragments". Move the text 
> from Section 4 "Extensions to WS-Transfer" section in WS-RT to this 
> new section subject to global namespace/prefix/name changes agreed as 
> a result of the rest of the proposal.
>
> - Replace the first sentence of this section:
> "WS-Transfer defines operations to Get, Put, Create and Delete 
> representations of resources. WS-ResourceTransfer extends these 
> operations to add the capability to operate on fragments of the 
> resource representations. "
> with the following:
> "Implementations of WS-Transfer may optionally support fragment-based 
> access to resources. This section describes the key aspects of such 
> support."
>
> Faults
> ------
>
> Proposal:
>
> - Remove WS-RT Sections 5.1 wsa:DestinationUnreachable and 5.2 
> wsa:EndpointUnavailable. These faults are defined in the ws-addressing 
> spec and should not be duplicated.
>
> - Add remaining faults from WS-RT to the fault section to in WS-T. The 
> merge of these faults will be subject to namespace/prefix/name changes 
> agreed in the wider context of this proposal.
>
> - The wsrt spec explicitly states how fault properties bind to the 
> soap 1.1/1.2. WG needs to agree whether this is useful information or 
> redundant and migrate to WST/omit accordingly.
>
> - Create a separate issue to investigate whether it would be possible 
> to combine some of the faults. For example, wsrt:InvalidExpression may 
> be a flavour of wst:InvalidRepresentation distinguished by the detail 
> element.
>
>
> Security Considerations
> -----------------------
>
> WSRT contains a subset of the security considerations contained in WST 
> so no action required.
>
>
> References
> ----------
> Add references to WS-I BP 1.1 and WS-MetadataExchange that are in WSRT 
> to WST.
>
>
> Appendices
> ----------
>
> - Add appendix B Resource Metadata Content from WSRT to T (subject to 
> namespace/prefix/name changes agreed as part of rest of proposal).
>
> - Appendix C - Combine the aspects of the XML schema in WSRT with 
> WST's XML schema (again subject to global namespace changes etc)
>
> ------------------------------------------------------------------------
>
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU/
>
>
>
>

Received on Saturday, 7 March 2009 00:37:07 UTC