Re: Should specifications take sides in the httpRange-14 debate?

On 21 November 2012 06:08, Stéphane Corlosquet <scorlosquet@gmail.com>wrote:

> Several members of the WebID CG met last month at TPAC, and one major
> outcome backed by timbl was to standardize WebID on hash URIs because they
> are easier to implement/deploy compared to 303s. Quoting from the new spec
> [1]:
>
> A WebID is a URI with an HTTP or HTTPS scheme, containing a URI fragment
>> identifier (i.e. a # symbol) and which uniquely denotes an Agent (Person,
>> Organisation, Group, Device, etc.). The URI without the fragment identifier
>> denotes the WebID Profile page.
>
>
> This decision made a few members of the group uncomfortable including
> myself [2-4] and generated a lot of discussion on the mailing list. I
> wasn't at TPAC to hear Tim's arguments, but I got to meet him today and
> asked about his reasoning. Note that I've never been against hash URIs, and
> I agree that they make sense for WebID (and many other scenarios). I use
> them myself. What makes me and others uncomfortable is to see a spec taking
> sides in the httpRange-14 debate by mandating one approach, when this
> debate is still on-going and some people are working on a possible new
> resolution. Should specifications relying on HTTP URIs take sides and pick
> a "winner" in the httpRange-14 debate? I would much rather see these
> specifications refer to the appropriate standard for publishing
> non-information resources on the Web. I know we don't have such standard
> today (at least one that people are happy with), and that's part of the
> problem. I see at least a couple of risks for a specs like WebID to set in
> stone a specific kind of URI. First, it means that whichever new resolution
> that comes out of the debate might make the existing WebIDs obsolete..
> Secondly, having deployment of one kind of URI might influence the TAG
> towards choosing the most deployed method to avoid any disruptive
> resolution, when a disruptive resolution is maybe what is needed.
>
> If Tim fells strongly about hash URIs based on the experience of several
> members of the community who got burnt with deploying 303 redirects, I'd
> like to ask that such recommendation be formalized at a higher level than
> each individual spec, so that groups writing specs such as WebID don't have
> to go through the same permathread over and over. How close are we with
> regards to a potential resolution of httpRange-14? What needs to happen to
> reach such resolution? What do you recommend us to do in the meantime? Are
> there precedents where specifications mandated a type of URI deployment? If
> the TAG isn't willing to find a resolution, is there any Working Group
> which might be interested in pursuing this goal? LDP?
>

It's necessary each individual spec to take views on a number of things.
For example, what is in scope, naming, which technology stack is
appropriate, adoption as well as building on the recommendations of other
specs.  Not just with this issue, but in a great number of specifications,
multiple changes occur regularly, you are sometimes hitting a moving target
and that's part of the challenge, to find that right balance.

I think it's important to respect the axiom of tolerance, which tries to be
inclusive as possible, yet also specific in what is described.  Do note
also that this very early draft spec is in flux and taking on board the
concerns raised.  Last I heard it was the consensus that verifiers MUST NOT
fail on the 303 pattern.

IMHO, the Web is an awesomely architected system, as evidenced by continued
exponential growth in the last 20+ years.  The TAG has done an amazing job
to date in protecting this stability, which, in turn, helps drive new
innovation.  Any new resolutions should aim to keep this momentum going in
a non disruptive way, which is essentially the W3C's mission of bringing
the Web to its full potential.




>
> --
> Steph.
>
> [1] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html
> [2] http://lists.w3.org/Archives/Public/public-webid/2012Nov/0135.html
> [3] http://lists.w3.org/Archives/Public/public-webid/2012Nov/0142.html
> [4] http://lists.w3.org/Archives/Public/public-webid/2012Nov/0137.html
>