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

Fw: Issue 6413 - Merge WST/T : Proposal

From: Katy Warr <katy_warr@uk.ibm.com>
Date: Tue, 10 Mar 2009 21:13:39 +0000
To: public-ws-resource-access@w3.org
Cc: Doug Davis <dug@us.ibm.com>
Message-ID: <OF02727910.492880E0-ON80257575.007433EB-80257575.007499E8@uk.ibm.com>
Here are 3 minor mistakes/improvements to the ws-t/ws-rt proposal that 
Doug and I noticed. 

1. The following text from wsrt:Put was accidentally omitted: 
"If a resource encounters a failure while processing the fragments in a 
Put request, it MUST generate a PutFault. The resource SHOULD ensure that 
its representation is unchanged from prior to the request, although atomic 
behavior is not required of resource implementations. The resource SHOULD 
include a wsrt:SideAffects element in the fault detail to indicate whether 
any changes occurred."

2. Merge copy states: 
/s:Envelope/s:Body/wst:Create/xs:any
"....All other children SHOULD be ignored by the service."
replace with:
"...All other children that do not have the wst namespace SHOULD be 
ignored by the service."

3. Proposal: 'Dialect' becomes 'ExpressionDialect', because that's what it 
is.

An updated proposal, with these amendments incorporated, is located here: 
http://www.soaphub.org/public/files/w3c/t-rt-merge-v2.doc

Thanks 
Katy

----- Forwarded by Katy Warr/UK/IBM on 10/03/2009 21:09 -----

From:
Doug Davis <dug@us.ibm.com>
To:
public-ws-resource-access@w3.org
Date:
06/03/2009 23:28
Subject:
Re: Issue 6413 - Merge WST/T : Proposal




All, 
  attached is an attempt to show what WS-Transfer might look like with 
WS-RT merged in.  Note that since the wrapper issue has not been 
incorporated into Transfer yet we had to quickly make those edits first, 
and accept those changes, so its possible those aren't 100% correct - but 
they should be close.  This should contain all of the edits that Katy 
mentioned in her original note (below) plus the changes for the other 
operations as well.  Some bits of text are highlighted or have comments 
attached - these are key talking points for our discussions.  Appologies 
if things aren't perfect, but this should give people a pretty good feel 
for what this proposal will result in.  Its important to note that this 
should not result in any feature changes - no features were add or removed 
- if this did happen during the merge then its a typo  :-) 



thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com 


Katy Warr <katy_warr@uk.ibm.com> 
03/05/2009 01:21 PM 


To
ashok.malhotra@oracle.com 
cc
Doug Davis/Raleigh/IBM@IBMUS, public-ws-resource-access@w3.org 
Subject
Re: Issue 6413 - Merge WST/T : Proposal









Hi Ashok 
Not forgotten but we wanted to get the Get one out first to give an 
indication to folk of the proposed direction. 
Rest in progress, 
thanks 
Katy 

From: 
ashok malhotra <ashok.malhotra@oracle.com> 
To: 
Katy Warr/UK/IBM@IBMGB 
Cc: 
public-ws-resource-access@w3.org, dug@us.ibm.com 
Date: 
05/03/2009 18:18 
Subject: 
Re: Issue 6413 - Merge WST/T : Proposal





What about the other verbs? 
WS-T defines PUT and DELETE and WS-RT defines PUT, CREATE and DELETE

All the best, Ashok


Katy Warr wrote:
>
> 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/
>
>
>
>
>
>






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 




[attachment "t-rt-merge-v1.doc" deleted by Katy Warr/UK/IBM] 






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 Tuesday, 10 March 2009 21:15:29 GMT

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