RE: Issue 6413 - just thinking

Let's put it this way... why is "Format" in WS-Eventing instead of a 
separate spec?  Because its WS-E specific.  Fragments are the same thing. 
Look at this from a newbies perspective, why is this one feature going to 
be in a different spec?  The "simplicity" argument won't hold true for 
them since *2* specs are more annoying/complex to deal with than one. This 
is why I'd prefer to see clear argument for why they _must_ be separate 
because until someone can come up with a usecase for using fragments 
outside of Transfer I have no good way to explain why (to those analysts 
that were giving me heck :-)  why we did this split (without feeling like 
I'm making stuff up anyway).

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> 
05/06/2009 10:34 AM

To
Doug Davis/Raleigh/IBM@IBMUS
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>
Subject
RE: Issue 6413 - just thinking






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