- From: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
- Date: Fri, 22 Mar 2013 09:48:46 -0400
- To: "public-webid@w3.org Group" <public-webid@w3.org>
- Message-Id: <22AEF936-A680-4911-8985-5F637945C345@openlinksw.com>
All -- The bulk of the past several WebID Community Group calls has been lost to rehashing (pun somewhat intended) the definition of WebID, and trying to move on from there. I am hoping that the following will help us to finally get past this, and to start making real progress on developing both the conceptual and functional specifications. In sum -- In October, we had one spec document [a], which horribly blurred the lines between conceptual and functional, and tried to handle both things at once. This led to the very broken definition of WebID that came out of TPAC. [a] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html In November, we still had just the one document, and in a long call with TimBL and others (who mainly haven't joined since), where we concluded that we *should* have *two* (to start, with more to come in time), with clear separation between the broad conceptual spec and the much more targeted and thus much more limited functional spec. In December or January, a new document [b] was created, to be the conceptual spec. The original doc was to be replicated into [c] and have the content which was redundant against [b] removed, thereby to become the first functional spec -- i.e., WebID-over-TLS. As I understood things, [a] was then to be discarded except for historical purposes. [b] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html [c] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/auth-respec.html The functional spec [c] was to be intentionally narrow in focus, dealing only with HTTP URIs for WebIDs, and showing only hash- based URIs in the examples, all intended to make the early implementer's job easier -- all as discussed in that November concall. The conceptual spec [b], on the other hand, was to retain the original breadth of vision -- see ISSUE-42 [d], ISSUE-55 [e]) -- among other things, allowing for other URI schemes (whether FTP, SPDY, LDAP, or otherwise), getting specific only where vital -- i.e., *URI dereferenceability.* [d] http://www.w3.org/2005/Incubator/webid/track/issues/42 [e] http://www.w3.org/2005/Incubator/webid/track/issues/55 Since then, we've been going in circles, re-blurring and re- clarifying the lines between conceptual and functional, and even as everyone on recent calls has agreed that *conceptually* speaking, a WebID should be "a dereferenceable URI", we no sooner agree on that than someone says that we voted to define a WebID as "an HTTP(S) URI" ... entirely overlooking or ignoring the fact that the ballot was not clearly written to say whether the question was regarding the definition to be used in the *functional* spec (as I was thinking) or the *conceptual* spec (as it seems some *may* have been thinking), and that the voting took place while there was still only *one* spec. Re-reading ISSUE-55 just now, I saw again the quote DanBri put in from TimBL's DesignIssue "Axioms" [f] -- "There is a lot of flexibility and growth to be gained by allowing any sort of URI, not one from a particular scheme, in most circumstances. Similarly, one should not make assumptions about the schemes involved. This is a facet of the particular parameters about how the technology is used. The choice of type URI in a [practical] use of a language is an important flexibility point." [f] <http://www.w3.org/DesignIssues/Axioms.html> -- and I was inspired to go look at Axions once more myself. There I found this remarkably relevant gem -- Axiom: Opacity of URIs The only thing you can use an identifier for is to refer to an object. When you are not dereferencing, you should not look at the contents of the URI string to gain other information. In other words -- whether it contains a hash or not; whether its scheme is http or spdy or lmnop; whether it's short or long, human comprehensible or pure gibberish -- all of this must be ignored *except* when *actually dereferencing,* which is not conceptual, but functional. PROPOSAL: WebID Definition *for the Conceptual Spec [b]*: A WebID is a URI which denotes an Agent, and which, when dereferenced, yields a document which describes that same Agent, which document includes internal statements which self-describe it as describing that Agent, *and* which use the same URI as was dereferenced to GET that this document to identify that Agent. (This URI need not be the *only* URI which identifies this Agent, nor even the *primary* URI used in this document.) Other definitions, restricting to HTTP(S) URIs, or otherwise, may be appropriate to particular functional specifications, such as the currently planned WebID-over-TLS. I will leave proposals for such until later (or for others to make). 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 Access, Integration, and Management Technology Providers
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Friday, 22 March 2013 13:49:15 UTC