Re: Uniform access to descriptions

Xiaoshu Wang wrote:
>   
> If you think that I have insulted you.  I apologize because that is 
> never my intension.  But let be honest, if you admit I did tell you a 
> solution, regardless if it fits your preference, then, did you really 
> think it out of your box.  If you had, why you said Conneg CAN NOT?
> 

I didn't say I was insulted.  I said that resorting to hurling
ad-hominem insults at those you disagree with is not conducive to
rational discussion.  I thought your solution through very carefully,
and like I have said twice before it is not in keeping with proper Web
architecture.  You take this to mean that I did not read your paper, or
did not understand it, perhaps because you are in a state of denial
that you could be getting it wrong.  No, what I meant was that I read
and understood your issue, but I think it is wrong.  Deal with that.

If there is more than one RDF document to be attached to a resource,
then one can either use multiple Link headers or multiple <link/>
elements, but not with content negotiation which can only redirect the
client to ONE option when there may be more.  This limitation is
overcome easily enough with the Link header.

>
> In fact, Conneg didn't violate RFC 2616.  Using LINK does because it
> is not in it.  It was in previous spec but that doesn't mean it is in
> the current draft. 
>

Content negotiation, per se, is not a 'violation' of RFC 2616.  Your
implementation of it, however, *is*.  I say this to you as a Web
developer of 15 years experience, 10 with content negotiation, not out
of ignorance, malice, failure to read your proposal, a closed mind, or
any other such label you tend to apply to my feedback.  Disagree with
me if you must, but don't try to convince others I am wrong by hurling
accusations about ulterior motives or character flaws or ANYTHING else
of the sort.

Now, for the umpteenth time I have come across in this thread, you are
claiming that the Link header is "not part of" HTTP.  You have been
told, repeatedly and by those who actually WROTE the spec, that just
because something was omitted from RFC 2616 does not mean it isn't "in"
HTTP.  The only way to take something "out of" HTTP would be to
deprecate it -- failing to carry the PATCH method or the Link header
over into RFC 2616 does NOT deprecate them and does NOT mean those
aspects of HTTP are not to be used.  How many people who wrote RFC 2616
does it take to tell you this?  Link is not in RFC 2616, but it IS in
HTTP by virtue of being in RFC 2068.  Please get this through your head
instead of constantly harping on a point that everyone on this list
disagrees with you about, because we choose to believe what HTTP's
authors tell us about Link (and PATCH) instead of your worldview.

>
> > Is it?  The client wanted an RDF document, I don't recall there
> > being any way for a client to state that it only wants a variant
> > representation and does not want to be redirected to a related
> > resource.  It is not possible to know EXACTLY what the client wants
> > if it's asking for only application/rdf+xml because that might mean
> > a representation in RDF format, or it might mean a standalone RDF
> > file that describes the requested resource, because we're dealing
> > with RDF here, not HTML.  In the end, like I said, [d] must be
> > parsed -- so [d] should contain an assertion describing [a].
> >   
> If GET x ACCEPT application/rdf+xml is not clear, I don't know what
> it is clear.  Again, I never said that you CAN NOT redirect.  Check
> all my arguments against LINK or your suggestion, did I said you
> CANNOT do that. Isn't you who have repeated said that something
> CANNOT be done. My point of view is always that you CAN DO without
> LINK, without worrying httpRange-14.
> 

Right, I have read your position, many times now in this thread, but I
still say you are wrong that content-negotiation is a *replacement* for
using the Link header.  As I and others have attempted to show you, it
is not.  The only time I used the term 'CANNOT' was to emphasize that
there is a difference between *not* sending a Content-Location header,
and *not being able to* send a Content-Location header even if you
wanted to.  If you CANNOT send Content-Location with your conneg
results, then you have broken with Web architecture, whether you *want*
to send that header or not.  Have you been reading MY posts?!?

>   
> But, sometimes we do need that to see some seemingly minor thing's 
> higher significance. This is part of scientific investigation: to 
> systematically compare things of similar nature. This is how we
> progress our understanding of reality. 
> 

However, we are discussing a technological issue which may be fully
defined using technological terms which everyone but you seems to
understand.  Instead of learning what those terms mean to others, you
fall back on strawman arguments in an effort to make others understand
what those terms mean to *you*.  Unless absolutely necessary, could you
please refrain from strawman arguments about technological issues?

>   
> Isn't it httpRange-14 that have injected FUD into the web.
> Otherwise, why the httpRedirect-57? And some other arguments in the
> issues, such as like version document.  I am simply trying to do the
> opposite and telling people to be free of that httpRange-14 FUD.  (I
> don't know what FUD is.  My definition is through looking up
> wikipedia.)
> 

No.  FUD is the response of those who do not like the httpRange-14
solution and can't express their opposition to it in technical terms
which others can understand.  Vague notions of Fear, Uncertainty and
Doubt will not convince anyone that httpRange-14 is in error, let alone
constitutes FUD.

>
> For the FUD you referred, it is not that I try to show that I have a 
> higher moral ground.  Engineer wise, I took Occum's razor seriously
> so I will always take the simplest approach that I can think of.
> Science and social wise, I do believe we all bear certain
> responsibility to community and society as a whole.
> 

The content-negotiation implementation in your paper shows exactly the
opposite of the KISS principle (Keep It Simple, Stupid), which I think
is what you meant rather than Ockham's Razor which states that, all
else being equal, the simplest explanation is usually the right one.

> 
> Emotion is an evoked feeling, attitude is one of them.  Whether I
> have an "ad hominem" or not does not entirely depend on what I said.
> It also depends on how the receivers take it.  I may not appear to
> you or others as a polite, articulate, or diplomatic person.  But
> that has nothing to do with what I tried to argue.
> 

Yes, I'm afraid it does.  When someone disagrees with you, try to avoid
responding to that by stating that there must be something wrong with
that person's reasoning (or they have an ulterior motive, haven't read
what you wrote, etc. etc. etc.), and instead try to explain your point
again -- because those ad-hominems have nothing to do with the point
you are trying to make.  Even if nobody does take offense, it is
incredibly BORING to have to keep ignoring remarks like that which
have NOTHING to do with the argument you are trying to make

>.
> Consider, you told me that I am the first one to say that you think 
> inside your box. But seriously, don't you think that you indeed did 
> that?
>

No, absolutely not.  My response to your example is based on my
experience.  I'm not going to ignore my experience with what doesn't
work, in the hope that somehow a magic pony will come along and make it
work because the Semantic Web is somehow involved.  Charging those who
disagree with you, with being unable to comprehend you because of their
inability to imagine that what you propose MIGHT work, won't win anyone
over to your side.  Even thinking out-of-the-box, my professional
expert assessment of your content-negotiation arrangement remains, that
it needs to be refactored.  Perhaps you're thinking inside your box?

>
> won't be the last one to say that too.  You take criticism too
> personally.  So what? - if we all think in the box once in a while,
> because we are all humans and to be flawed is only natural.  I carry
> a lot of flaws as what you suggested.  But if you assume that I
> didn't have bad intension and that I have an attitude as a natural
> consequence of me being human, how are you going to feel about my "ad
> hominem".
>

Now you are making the ad-hominem assertion that I take criticism too
personally.  No, buddy, I am simply begging you to make your arguments
RATIONALLY instead of cluttering up this list with incessant noise
about what you think might be wrong with other people.  It serves no
purpose, whether anyone takes offense or not!!!  So please STOP!!!
Fine, you have an attitude as a natural consequence of being human --
so do I but that doesn't mean I can't behave like a professional in a
technical discussion, by checking my attitude at the door.

>
> Eric, I have repeated many times that I didn't say Location-Header
>> is 
> not useful.  What I was trying to say is that I have a specific use
> case that doesn't desire Location-Header. I am simply illustrating
> the possibility of CAN do attitude.  I don't implement server, at
> least not right now.   Do you trust me that I can implement some sort
> of cache solution, it is engineering at last, right?  It may do
> something different than the HTTP protocol, which I don't have time
> to read its caching mechanism, but my application will deal with
> specific client so if I need it I can do it. 
>

Oh, good GRIEF.  You're seriously participating in this thread and
telling me that I don't understand caching, without having even READ
that part of the spec?  This sort of thing tends to convince me that
your purpose here is trolling, not listening to what others have to
say.  Why don't you trust me that if your application can only cache
its output if you engineer a non-HTTP solution to the caching problem,
that it is not conforming to RFC 2616?  What part of this are you not
understanding?  If your application CANNOT be made to send a Content-
Location header, this is completely different from choosing not to send
one for whatever reason.  An application that CAN send Content-Location
is perfectly within the spec even if it CHOOSES not to.

Your specific use-case of not needing a Content-Location header, once
again, is convoluted, does not conform to the intent of the spec, and
is therefore a fringe case.  *If* you can come up with an example that
doesn't send Content-Location but COULD be made to without throwing it
out and starting over and refactoring, then I will reconsider your
position.  Until then, my professional opinion remains that your
example is so far from a conformant Web architecture as to have no
bearing on this discussion.  Come up with a better example, or accept
that I may be right instead of continuing to deny that possibility.

>   
> My position is, in fact, very simple - that is: the current web is
> fine and can work without much extension.  I am simply trying to tell
> people that we can work with what we already had. I hold - in fact -
> a positive attitude toward the web.  It is an engineering project at
> last, we can do a lot of meaningful things by opening our mind.
>

Agreed.  I took an open-minded, out-of-the-box approach to your
argument.  But in the end, interoperability is achieved by agreement on
interpretation of specs.  Your solution sacrifices interoperability,
even if others follow it, because the result is not conformant to Web
architecture.  You can do anything out-of-the-box you want with the
specs, except violate them at every turn because you disagree with
them.  There are many open-minded, out-of-the-box solutions out there
that nobody has thought of yet, but which would conform to HTTP.  Just
because someone evaluates your solution and says it does not conform,
is not an indictment of that person's inability to reason, or a closed
mind, or whatever.  Have you stopped to consider that you might be
wrong?

>
> But it is you that constantly told me that you CANNOT do this and
> CANNOT do that.  I have never said the same to you.  I have always
> said that you sure can do it in the old way, but you don't have to.
> To use Tim's argument to support mime, that is why should the concept
> of the web has to be limited by the concept of IP/TCP's "packet',
> then why should the concept in the new semantic web has to be limited
> by the concept of pre-semantic web?
> 

I haven't told you that you CANNOT do anything, as I explained above.
But I will tell you when your example is a fringe case which goes
against Web architecture.  I don't have to accept any wild and crazy
idea postulated to prove that my mind is open, because it comes back to
what the agreed-upon interpretation of the spec is -- which doesn't
forbid thinking out of the box or having an open mind, it just means
there are LIMITS to what you can do without breaking conformance with
the specs.

>
> Sure, we both have a box, mime is a technical one, yours is a
> conceptual one.  Do you agree?  No, I guess not. So, sorry, you don't
> have a box. But I do have one - that is the web we have.  I tried to
> expand my conceptual box so I can do more things for me with what we
> have. Is that fair?
> 

There's that attitude again.  I think outside the box on HTTP, that
doesn't mean I believe that I'm somehow immune from inside-the-box
thinking on HTTP or anything else.  You can certainly expand your
conceptual box of what the Web is, but you have to be prepared to be
told that you are wrong, which clearly you are not.  I probably get
told that I'm wrong on HTTP more than just about anyone, and I sure do
defend my positions, but in the end I am willing to admit when my
solutions don't conform to Web architecture -- that's how we learn.
When it comes to outside-the-box HTTP solutions, I don't expect to
always be right, and often I am not.  This makes me a moron-expert [1].

>
> (For all those *insult*, *attitude*, *ad hominem* that I have put on
> you or other people. I am sorry, O.K?    But can you check those for
> me at your door, please?  I am sometimes too self-centered or
> self-obsessed so I may not be able to be aware any of that.  But I
> can assure you that harming other person's feeling is never my
> intension.)
> 

I didn't think it was.  But the fact that you do respond in such a
fashion drops the signal-to-noise ratio of your posts dramatically.
Try to stick with signal, and avoid the noise caused by asserting that
the only reason people disagree with you is because there must be
something wrong with them.  It just might be possible that YOU are
wrong, in which case you should open your mind to what others are
telling you so that you can learn, instead of insisting that the spec
is broken or other people are mental midgets incapable of intellectual
thought, or anything else which indicates to others that you are not
capable of being wrong, because only you are thinking outside the box.

Either respond professionally, or don't respond at all, because if you
continue as you have I will simply ignore you.  This list is NOT an
appropriate venue for flaming, and your posts are crossing that line.

-Eric

[1] http://diveintomark.org/archives/2004/08/16/specs

Received on Tuesday, 15 April 2008 00:54:26 UTC