Re: hash editing: removing apple bug ref from SHOULD

On Dec 6, 2012, at 05:19 PM, Henry Story wrote:

> 
> On 6 Dec 2012, at 22:59, Ted Thibodeau Jr <tthibodeau@openlinksw.com> wrote:
> 
>> 
>> On Dec 4, 2012, at 01:56 PM, Henry Story wrote:
>> 
>>> 
>>> On 4 Dec 2012, at 19:39, Ted Thibodeau Jr <tthibodeau@openlinksw.com> wrote:
>>> 
>>>> 
>>>> On Dec 4, 2012, at 01:05 PM, Henry Story wrote:
>>>> 
>>>>> 
>>>>> On 4 Dec 2012, at 18:51, Ted Thibodeau Jr <tthibodeau@openlinksw.com> wrote:
>>>>> 
>>>>>> 
>>>>>> On Dec 4, 2012, at 12:14 PM, Henry Story wrote:
>>>>>>> This is why I brought this up here. Can you defend why the Apple
>>>>>>> key chain is a reason against the SHOULD? Then if you want we can 
>>>>>>> get some feedback and see where the community stands on this.
>>>>>> 
>>>>>> See --
>>>>>> 
>>>>>> <http://lists.w3.org/Archives/Public/public-webid/2012Dec/0019.html>
>>>>> 
>>>>> [[
>>>>> When a user clicks on a URI with a hash in Keychain.app, they're
>>>>> not going to get where the URI generator intended.
>>>>> 
>>>>> The user is going to have a bad experience thereby.
>>>>> 
>>>>> Mandating, or even strongly encouraging, hash URIs for WebID
>>>>> will increase the odds of this bad experience for Mac users
>>>>> who start to explore how this all works.
>>>>> ]]
>>>>> 
>>>>> yes, understood. But
>>>>> 
>>>>> 1. it is a bug in a little used Apple tool that has very
>>>> 
>>>> "little used" is a baseless opinion.
>>> 
>>> You are making the statement that it is used to click on something. Please
>>> prove that it is widely used.
>> 
>> I said that the tool is widely deployed.
>> 
>> I have made no assertions about its current usage levels,
>> which I do not dispute are far from its deployment.
>> 
>> You have asserted that it is a little-used tool, and based
>> on this current usage level, you seem to believe that it
>> will remain so -- even when the technologies we're trying
>> to boost here increase uptake, and users therefore have 
>> added incentive to use this pre-installed and easy-to-use 
>> (albeit apparently buggy) tool.
>> 
>> 
>> 
>>>>> little impact on anything, 
>>>>> and this is a standards process, so we don't base our standards on broken tools. What
>>>> 
>>>> Actually, we do.
>>>> 
>>>> "Be liberal in what you accept, and conservative in what you emit."
>>>> 
>>>> This guideline stems from decades of work on internet messaging
>>>> (RFC 821/822 and their successors, among other threads).
>>> 
>>> Still the SHOULD gives you the wiggle space for this.
>>> 
>>>> 
>>>>> if they fix it tomorrow?
>>>>> 2. the SHOULD allows you to do something else if you have valid reasons. I cite RFC2119 on SHOULD
>>>>> [[
>>>>> SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
>>>>> ]]
>>>>> Since you fully understand the implications the SHOULD would allow you to do that.
>>>> 
>>>> I will remind you that I was and am not a blocker on SHOULD, 
>>>> even if I am and remain negative thereon.
>>> 
>>> ok. I am not sure where I stand, and am looking at the arguments
>>> as they appear on the wiki. It does not help if one puts an argument
>>> against SHOULD that does not argue against SHOULD.
>> 
>> 
>> I'm asserting that my argument against MUST is *also* an
>> argument against SHOULD and for the far looser MAY.
>> 
>> 
>>>>> 3. There is another workaround: just  redirect 
>>>> 
>>>> *Our* tools will redirect.  We'll build in handlers for whatever
>>>> weirdness the net throws at us.  
>>>> 
>>>> That's part of what OpenLink does, and a big part of why DBpedia 
>>>> worked in the first place (Virtuoso being one of few servers that 
>>>> was built to deal with IE's broken behavior of sending the #frag
>>>> as part of its GET, unquestionably violating HTTP spec).
>>>> 
>>>> But today's effort is about *interoperability*, about making sure 
>>>> that the most tools possible will work with each other.
>>>> 
>>>> I want *other* tools to either handle these issues, or -- far 
>>>> better! -- not have to address them at all.  
>>> 
>>> yes, I believe the interoperability arguments are already up on the
>>> wiki. So I don't see why adding an argument against SHOULD that does
>>> not make a case against SHOULD is helping.
>> 
>> The fact that you don't *see* it as making a case against SHOULD
>> does not make it a fact that it *doesn't* make such a case -- and
>> I assert once more, it *does* make a case against SHOULD.
>> 
>> 
>>>>> http://some.eg/foaf%23
>>>>> 
>>>>> to
>>>>> 
>>>>> http://some.eg/foaf
>>>> 
>>>> Note that such redirections will not typically be from something 
>>>> ending foaf%23 but something ending foaf%23fragID, *and* it won't
>>>> be applicable to *every* GET with %23 in the requested URI...
>>> 
>>> yes my typo.
>> 
>> What's the typo?
>> 
>> OH!  Are you saying that you meant to say there, that the
>> redirect should be from <http://some.eg/foaf%23.*> to
>> <http://some.eg/foaf#.*>, where the ".*" is means as regex
>> "0-infinite wildcard"?
>> 
>> 
>>>> And, even if it were applicable to every GET, it's not nearly 
>>>> trivial to set up on most web servers, or so I've gathered from 
>>>> witnessing many people trying to do so.
>>> 
>>> I think that is why people are arguing that #uri must be a SHOULD.
>>> ( At least that is one of the arguments up on the wiki - it's under MUST,
>>> but I guess it could also be under SHOULD )
>> 
>> Again -- 
>> 
>> If the # is SHOULD, and tools are percent-encoding that 
>> character at various points, and other tools are *not* 
>> percent-decoding, then the end result will be MANY ERRORS,
>> and poor user experience, until and unless implementors
>> all decide to break the SHOULD with the justifiable argument
>> that IT BREAKS THE EXPERIENCE.
>> 
>> Thus -- the # should *NOT* be SHOULD, and people who are
>> implementing WebID functionality should have the freedom
>> to choose hashed or hashless based on their audience/target
>> user-base (say, if your target is Mac users, you won't want
>> to use hashed, because of the issues I've highlighted ...
>> but you'll be trading off some degree of performance ...
>> though that performance could be lost even *with* hashed
>> URIs if you 303 at some other point for whatever reason...)
>> 
>> 
>>>>> So your argument is not an argument against SHOULD given the
>>>>> definition of SHOULD.
>>>> 
>>>> My argument *is* against SHOULD, and *for* MAY, given the 
>>>> underlying goal -- maximizing interoperability.
>>> 
>>> Your general position is against SHOULD and for MAY, and that
>>> is a perfectly reasonable case to argue. 
>> 
>> Yes, and gee, thanks.
>> 
>> 
>>> But this particular argument ( the one I removed from the wiki )
>>> does not work against SHOULD.
>> 
>> Yes, I say again, it does.  Just because you don't see it,
>> doesn't mean it isn't there.  (Black swan!  Open world!)
> 
> This is a question of logic. That is I am taking all possibilities
> into account. Your argument still does not work against SHOULD
> since 
> 
>  1. SHOULD allows you for good reasons to make exceptions, 
>     ( and you claim to have a good reason )

SHOULD allows *implementors* to make exceptions for good 
reasons.

I am suggesting, strongly, and more strongly by the minute,
that the spec SHOULD NOT set things up such that implementors
go down a known-flawed path (i.e., hashed URIs) until they
run into enough road blocks to each decide that they have
good reason to NOT conform with the SHOULD advice.


>  2. you have the  redirect from http://profile.eg/joe%23me to http://profile.eg/joe 
>     as an option.

Yes, and setting things up such that all deployers/users have
to handle this painful scenario is *definitely* going to increase
uptake and usability of WebID technology....

Or maybe, not.


>>> You may have already enough arguments against SHOULD for all I know.
>>> Adding arguments that don't argue against what you wish to argue against
>>> is not helping.
>>> 
>>> In fact I gave you a powerful extra argument for the third MAY solution 
>>> today: 
>>> - SPDY: with SPDY, my arguments against redirects is a lot less strong.
>>> - Caching of 303s: if that is correct then it removes a little bit of sting
>>> ( but I'd like Nathan to point to the Httbis spec )
>>> 
>>> I would like to see arguments that help us make progress.
>> 
>> 
>> Indeed.  Then please don't simply paint over the ones with 
>> which you disagree.
> 
> I am pointing out logical impossibilities in arguments, those
> are the ones I am picking out at present. Not arguments with
> whose conclusions I disagree - I have not made up my mind what
> the conclusion should be. 

If you delete an argument from the wiki page, you've painted 
over it.

If it's impossible, point out the impossibility, and be done.

My logic may have flaws -- but I've yet to see you point out
a fatal one, which an impossibility would be.


>> We're working with intelligent people who can evaluate our
>> arguments themselves -- and should have the freedom to do so.
> 
> I consider myself intelligent, and well versed in logic. And your
> argument just does not work.

"...for me," that is, for Henry.

Kindly allow others to form their own conclusions by not 
censoring topical arguments on wiki pages.


Perhaps the logical consistency of my position ("WebID SHOULD be 
HTTP URI", period, end of sentence, "MAY be hashed" is left to 
be inferred [or not] by the reader; I'll tolerate MUST be HTTP 
for this iteration) has might be confirmed by your consideration 
of this question --

   Why does the Linked Data meme (Five Star or original form)
   stop at "HTTP URIs", and not say "hash-based HTTP URIs"?

Presuming WebID is meant to align with Linked Data (and that is
definitely one of my presumptions), I have yet to see a strong
justification for WebID to go further than Linked Data along
this line...  

And we're back to "WebID MUST be URI, SHOULD be HTTP(S) URI," 
full stop.

Ted


--
A: Yes.                      http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
                             //              http://twitter.com/TallTed
OpenLink Software, Inc.      //              http://www.openlinksw.com/
         10 Burlington Mall Road, Suite 265, Burlington MA 01803
     Weblog   -- http://www.openlinksw.com/blogs/
     LinkedIn -- http://www.linkedin.com/company/openlink-software/
     Twitter  -- http://twitter.com/OpenLink
     Google+  -- http://plus.google.com/100570109519069333827/
     Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers