- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Fri, 22 Mar 2013 15:14:16 +0100
- To: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
- Cc: "public-webid@w3.org Group" <public-webid@w3.org>
- Message-ID: <CAKaEYh+GWsE1jPgD0moiBhUcQRkC5wgUBPp2KrEH=TsyzjuKMA@mail.gmail.com>
On 22 March 2013 14:48, Ted Thibodeau Jr <tthibodeau@openlinksw.com> wrote: > 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. > +1 Axioms make awesome reading If you will note the TOII (Test of independent invention) you'll come to the conclusion that in the long term a WebID can only have one reasonable definition and that is a "URI that denotes an Agent" -- in the sort to medium term the definition will be a variation of this, in order to get things done. > > 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. > Opacity is an ideal which is NEVER actually used in practice. Consider a URI, you introspection on the string before the : to find out the protocol. Similarly, you will parse an HTTP URI in accordance with the HTTP regular expressions, gleaning from it what you can. That said, it's better to be opaque if you can. > > > 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.) > A bit of a mouthful. I made my mind up on this 1-2 years ago, and that is that I will support the consensus view. I'm keen to see WebID shipped, whatever the smaller details are, I know in my mind what a WebID is and what it can be used for. > > > 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 > > > > > > > >
Received on Friday, 22 March 2013 14:14:45 UTC