RE: Issue 6413 - Merge WST/T : Proposal

Gil,
You are only potentially reducing the complexity for the current RT users (who are they anyway?).
You are certainly NOT reducing the complexity for the large number of Transfer users (in fact I could argue that you are increasing it).
--Geoff

From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
Sent: Friday, March 06, 2009 4:58 PM
To: Geoff Bullen
Cc: Katy Warr; public-ws-resource-access@w3.org; dug@us.ibm.com
Subject: Re: Issue 6413 - Merge WST/T : Proposal

It's always more complex to have two ways of doing "the same" thing. WS-T and WS-RT do the same thing, so it reduces complexity to combine them.

- gp

Geoff Bullen wrote:
No one has yet answered the questions I posed earlier...

What is the justification for adding all this complexity and making all these changes?
(Each person's additions seems to add even more complexity.)

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.

--Geoff


From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
Sent: Friday, March 06, 2009 4:44 PM
To: Geoff Bullen
Cc: Katy Warr; public-ws-resource-access@w3.org<mailto:public-ws-resource-access@w3.org>; dug@us.ibm.com<mailto:dug@us.ibm.com>
Subject: Re: Issue 6413 - Merge WST/T : Proposal

Geoff,

It seems to me that all your concerns could be addressed provided the following two requirements were met:

1.) Support for fragment-level operations in (the new) WS-Transfer should be "truly optional". By "truly optional" I mean optional for both the provider and the consumer.

2.) There was some way (besides sending a message and receiving a fault) for a consumer to determine whether or not a provider supported fragment-level access. I'm thinking in particular about a WS-Policy assertion or sub-assertion which indicated that the endpoint in question supported fragment-level operations.

With these things in place it should be fairly easy for a profile or dependent spec to simply say "we don't support fragment-level operations" and leave it at that.

- gp

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:

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.

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).

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.

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> [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<mailto:public-ws-resource-access@w3.org>
Cc: dug@us.ibm.com<mailto: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> [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<mailto:public-ws-resource-access@w3.org>
Cc: dug@us.ibm.com<mailto: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