Re: Issue-57

On Wed, Jun 15, 2011 at 9:40 PM, Xiaoshu Wang <xiao@renci.org> wrote:

> I think there is one thing that we all should agree. That is: neither side
> is going to convince or accept the other side.
>

There are several issues being discussed. Are you saying that in none of the
cases will one side convince or accept the other side? Do you assert that we
can not have a resolution of these issues without both sides agreeing?


>
> But the thing is: these two views are not mutually exclusive. One view
> actually subsumes the other. Those view/practice of not caring for
> IR/httpRange-14 does not exclude those who insist on IR/httpRange-14. The
> latter community can, in fact, grow out of a world built upon the former
> viewpoint. They can develop an ontology of IR and assert their dataset
> with this ontology, and their use of URI will adhere to httpRange-14.
>

What is the alternative of http-range14 you are suggesting? What does "not
caring" mean, please? For your reference, here is the resolution:


<TAG type="RESOLVED">

That we provide advice to the community that they may mint
"http" URIs for any resource provided that they follow this
simple rule for the sake of removing ambiguity:

   a) If an "http" resource responds to a GET request with a
      2xx response, then the resource identified by that URI
      is an information resource;

   b) If an "http" resource responds to a GET request with a
      303 (See Other) response, then the resource identified
      by that URI could be any resource;

   c) If an "http" resource responds to a GET request with a
      4xx (error) response, then the nature of the resource
      is unknown.

</TAG>

Please specify which part you are referring to.

But the inverse cannot be held. The view of latter group entails a smaller
> universe. A web architecture based on the latter view will label the
> former's statement as "false", their authors "irresponsible", and their
> resources "illegal".
>

Of the three terms mentioned, I see only the term "irresponsible" and it has
been used by David, who I'm guessing you consider to be of the later view.

These are specifications and one hopes that one can arrive at determinations
of these sorts, whether or not anyone likes it.


> The question that TAG should answer, in fact, is not which viewpoint is
> right. (We know there would not be answer to it.) Rather, it should be:
> should we design the web architecture be in such that it fosters
> diversity or in such that it suits to someone's preference?
>

The TAG should figure out what the architecture is supposed to accomplish
and propose constituents of the architecture that let it do so.

Casting the issue as a matter of accepting diversity is as appropriate here
as it would be in a discussion of the format of TCP headers. If there isn't
agreement about which bytes specify the source port versus destination port
the damned thing won't work and the same thing is true here.

-Alan