Re: #URIs and redirections

Kingsley Idehen wrote:
> On 11/29/12 3:42 PM, Henry Story wrote:
>> On 29 Nov 2012, at 19:36, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>
>>> On 11/28/12 3:25 PM, Ted Thibodeau Jr wrote:
>>>> But the following, which Henry initially seemed to be
>>>> suggesting as better (though his conclusion seems otherwise)?
>>>>
>>>>>> -http://xmlns.com/foaf/0.1/knows#•
>>>>>> -http://xmlns.com/foaf/0.1/mbox#•
>>>>>> -http://xmlns.com/foaf/0.1/Person#•
>>>>>> -http://xmlns.com/foaf/0.1/Agent#•
>>>> These URIs don't look right in Mail.app.
>>>>
>>>> The URI highlighting stops at the last solidus ("/"), so
>>>> they all look like links to the same page --
>>>> <http://xmlns.com/foaf/0.1/>  -- and that is where clicking
>>>> them takes me.
>>>>
>>>> (I am then redirected to the same<http://xmlns.com/foaf/spec/>  as 
>>>> above -- but again, if the redirections were handled as
>>>> I suggest above, this end result would be very wrong.)
>>>>
>>>> Be seeing you,
>>>>
>>>> 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 Acchess, Integration, and Management Technology 
>>>> Providers
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> To cut a long story short, I've generated a certificate and produced 
>>> a screenshot [1] from my keychain instance. I have a hash URI 
>>> denoting the certificate issuer's alternative name (IAN) and a 
>>> hashless URI denoting the certificate subject's alternative name 
>>> (SAN). Clicking on the IAN leads to a 404 since the # was transformed 
>>> into %23,  a decision out of my hands as the end-user i.e., a bug in 
>>> keychain.
>>>
>>> As you know, we (historically) have little interest is going around 
>>> asking vendors to fix bugs in their products, on their on schedules 
>>> etc.. It's utterly impractical and a complete waste of time.
>>>
>>> Links:
>>>
>>> 1. 
>>> https://dl.dropbox.com/u/11096946/WebID/keychain-http-hash-versus-slash-uri-issue-interop-showcase.png 
>>> -- maybe a link for the relevant section of the for and against Wiki, 
>>> for future reference.
>> I can't remember if I put a bug report to apple for that. It's still 
>> worth doing it I think.
>>
>> In any case those types of bugs are not relevant to our hash uri 
>> issue. So I'll remove that
>> from our hash wiki later.
>>    http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition/hash
> 
> I am running out of patience with these kinds of comments from you.
> 
> You have an argument you don't like, then feel you have the unilateral 
> right to remove it from the debate? Why open up a Wiki at all?

+1 I'm afraid, if fragments aren't supported everywhere we need them to 
be, then that's an issue we need to consider - I know it's been 
mentioned before in other contexts and with other tooling by harry halpin.

I believe it would be in everybody's best interests to keep it in there 
and discuss this thing with eyes wide open.

Best,

Nathan

Received on Thursday, 29 November 2012 21:08:33 UTC