Re: Issue 6413 - just thinking

If it is not this fragment spec, then what fragment spec?
There was "no objections" today on the question of needing/wanting "a"  
fragment spec.
-bob

On May 5, 2009, at 8:43 PM, Doug Davis wrote:

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