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

RE: Issue 6413 - just thinking

From: Geoff Bullen <Geoff.Bullen@microsoft.com>
Date: Wed, 6 May 2009 07:34:29 -0700
To: Doug Davis <dug@us.ibm.com>
CC: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, "public-ws-resource-access-request@w3.org" <public-ws-resource-access-request@w3.org>
Message-ID: <5AAAA6322448AA41840FC4563A30D6E843A0748221@NA-EXMSG-C122.redmond.corp.microsoft.com>
Doug,
It appears that you continue to make technical arguments as to why the "merge T with RT" proposal is good but not provide answers to basic questions to build consensus:

1)      What does "strongly encourage" actually mean to you?

2)      All the other RA specs will be "strongly encouraged" by becoming W3C ratified standards, being well written, valuable and well interop tested.  Why is fragment access different?  Why must it be more "strongly encouraged" than the others?

--Geoff


From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Tuesday, May 05, 2009 5:43 PM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org; public-ws-resource-access-request@w3.org
Subject: Re: Issue 6413 - just thinking


Geoff,
  Allow me to turn it around for a sec... if the general premise of "strongly encouraging" is agreed to, and people do not "want a proliferation of fragment specs", then an obvious question (to me anyway) is: what's so bad about having it in Transfer?  I've heard (and understand but disagree with) your concerns about complicated Transfer, but if the fragment stuff really is optional then where's the harm?  By doing so we don't have to find the correct wording, marketing, convincing technique to have this link - its explicit in a very unambiguous way.  In the past you've said that some proposals might not have made it truly optional.  If so, perhaps we could look for a better mechanism by which we add it to Transfer to ensure this optionality really is present.  We've already talked about moving it to an appendix - is there more we can do?  Or perhaps showing where, in the current proposal, its not really optional.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.

Geoff Bullen <Geoff.Bullen@microsoft.com>
Sent by: public-ws-resource-access-request@w3.org

05/05/2009 07:43 PM

To

"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>

cc

Subject

Issue 6413 - just thinking







On thinking about this issue some more...

It appears that the main goal behind the proposal to merge T and RT is to (correct me if I am wrong here):
"Strongly encourage" (but not force) implementers to use the fragment access standard, instead of building their own. The example of WS-MAN having defined its own fragment support is often quoted.  No one wants a proliferation of fragment specs.

It has also been stated that the status quo, moving RT forwards as a standalone W3C ratified standard which composes with Transfer, is not seen as strongly encouraging.

The proposed solution, adding basic fragment support into the T namespace and putting the fragment spec text as an appendix in the T spec, is seen as strongly encouraging.

It has also been stated that one of the main factors in encouraging people to use a particular spec is for the spec to be well written, have good value and have proven interop.  That is one way important to encourage usage, but that also seems to fall short of the required "strongly encourage" mark.

Since the merging the specs seems to split the WG fairly evenly (4-3), is there any other way to "strongly encourage", without resorting to merging the specs?  I am just trying to get people the think more creatively about possible approaches that everyone can live with here.  What if we:
1)      Added normative text in the Transfer spec such that implementers MUST use Fragment access spec if they need that functionality with transfer?  Would that be "strongly encouraging"?
2)      What if the RA WG went to the WS-MAN group and convinced them to add to their charter that they would implement fragment access when they adopted the WS-RA specs?  Would that be "strongly encouraging"?
3)      Marketing campaign: "Don't fragment fragments" :)

These are just idea starters, they are not Microsoft proposals.  One of the issues here is trying to understand what "strongly encourage" actually means.   Or, by definition, can one only "strongly encourage" by merging the specs together?  Should the WG also "strongly encourage" Eventing? :)

--Geoff
Received on Wednesday, 6 May 2009 14:35:20 GMT

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