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? J
 
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? J
 
--Geoff