Re: Uniform access to descriptions

Let's stop here.  But I sincerely wish you refrain yourself from using 
"experience" as a justification for "truth". I know you dislike strawman 
example, so I won't give you any.  But I trust your intelligence and 
your "experience" can find many.

I have cited the following quote of Max Planck many times:  "A new 
scientific truth does not triumph by convincing its opponents and making 
them see the light, but rather because its opponents eventually die, and 
a new generation grows up that is familiar with it."

Just to remind you so to avoid hurt your (....): I am not implying that 
"my interpretation" is the /new/ one, nor it be the /truth/.  It is 
simply another "interpretation" or "theory".  I took knowledge evolution 
the same way as ecological evolution.  Eventually, the wisdom of 
community triumphs individual talents.

For the web, I simply want people to follow the few but nevertheless 
very important design principles underlined in the AWWW.  But on the 
other hand, I also want people to be free of impractical nuisances, free 
of unnecessary doctrine, and free of ambiguity. 

Regards,

Xiaoshu

Eric J. Bowman wrote:
> 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 10:50:25 UTC