Re: ACTION-350: Best practice for referring to specifications which may update

On 1/18/2012 1:30 PM, Roy T. Fielding wrote:
> On Jan 18, 2012, at 2:36 AM, Robin Berjon wrote:
>
>>> On Jan 18, 2012, at 03:10 , Larry Masinter wrote:
>>>>> What is too complex and ultimately wrong  is to give options to
>>>>> those writing specs that make references.
>>>
>>> I beg to differ. Ultimately, those who write specs are those most
>>> informed about how they should handle their own references (if
>>> they're not, then we have an entirely different problem). They are
>>> the ones who should be making decisions about whether the
>>> specifications they reference can be trusted to remain compatible
>>> and should therefore be loosely bound, or on the contrary (hopefully
>>> only in extreme cases) have a broken upgrade path and need an
>>> anchored reference.
> That's impossible.  The appropriate dependencies for a standard depend
> on the social context of its implementation at some future time.  Spec
> authors don't have a clue what that will be, nor whether it will be
> uniform across all implementation contexts.  That's why the Web's
> orthogonal technologies are supposed to be defined in orthogonal specs,
> and pretty much by definition orthogonal specs have loose bindings
> (unless they are dead).

Roy, please clarify. My impression is that Robin is endorsing latitude for 
authors, in part so they can go for loose coupling; my impression is that 
Larry is against loose coupling. Your "that's impossible" statement is 
physically positioned as being a response to Robin, but the content seems 
more at odds with what I take to be Larry's position.

In any case, it seems pretty clear that you're strongly in favor of 
allowing loose coupling, at least as a (very common) option, and perhaps as 
the only option.

FWIW: I think loose coupling should be an option, and for the reasons you 
state I think loose coupling will in many cases be the right choice, risks 
and all. I also think there are situations in which loose coupling is a bad 
choice, typically if one doesn't have sufficient bounds on the possible 
changes to have high confidence that security or interoperability won't be 
inappropriately compromised.

Noah

Received on Wednesday, 18 January 2012 19:46:49 UTC