Re: hash editing: removing apple bug ref from SHOULD

On Dec 2, 2012, at 05:56 AM, Henry Story wrote:

> I removed the following arguments from SHOULD since clearly they don't argue agains SHOULD
> since it would allow it.
> 
> [[
> 
> Ted Thibodeau
> * The '''Keychain Access.app''' in Mac OS X takes any SAN that includes a #, and visually presents it correctly.  But when you click on that URI (the textual string of which you cannot select and copy), your browser loads the URI with %23 in place of the # -- e.g., Keychain Access.app displays '''http://twitter.com/TallTed#this''' locally, but when I click it, my browser (observed with both Firefox and Safari; no reason to think any other would behave differently) tries to load '''http://twitter.com/TallTed%23this''' -- which correctly 404s.  Now, this is clearly a bug in Mac OS X and/or Keychain Access.app -- but this is a very widely deployed tool which demonstrates the folly of forcing a particular URI pattern for WebID.  (This is an argument against both MUST and SHOULD for hash-URI.)
> 
> Kingsley Idehen
> * Apropos the comments above from Ted, all you have to do is think about platform interop to see that SHOULD is still vulnerable to %23 transformation of # (fragment id) demonstrated by [https://dl.dropbox.com/u/11096946/WebID/keychain-http-hash-versus-slash-uri-issue-interop-showcase.png Mac OS X Keychain] which leads to [https://dl.dropbox.com/u/11096946/WebID/keychain-http-hash-versus-slash-uri-issue-interop-showcase-2.png THIS] empty page .
> 
> ]]

Again, I voice my disagreement and extreme dissatisfaction with 
this "removing arguments" practice. 

A page of pros and cons should include all such that people have 
raised, as well as the refutations of any positions which are 
demonstrated to have flawed basis.

Positions which are deemed irrelevant to the discussion -- by
group consensus, not by one individual, chair or otherwise -- 
may be removed to a new section of the page, or even to a side
page, but should *NOT* be summarily deleted.

The wiki history page is *not* a viable place for retention of
such, as nobody is going to go read revision after revision to
see what has been inserted and deleted along the way.

The wiki page was created to lower traffic on the mailing list,
and move discussion/argument/thread to the wiki page.  But if 
you're going to simply remove edits made to the wiki page, then
that commentary must be brought back to the mailing list, and
the whole point of the wiki page is nullified.


> Also could the OpenLink folks put their arguments together and not repeat each other? 


I would say not.  

We're speaking as individuals here, not corporately.

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