Re: making the webcredits.org spec more strict about 'source' and 'destination' fields.

On 24 April 2012 20:45, David Nicol <davidnicol@gmail.com> wrote:

>
> On Tue, Apr 24, 2012 at 11:14 AM, Melvin Carvalho <
> melvincarvalho@gmail.com> wrote:
>
>>
>> I think the subtle point here that most dont get, is that http urls are
>> documents as defined by the protocol.  And anything inside the documents as
>> denoted with a # are data points.  The hard thing in this is web developers
>> having to UNLEARN their previous assumptions.  This single point causes no
>> end of chaos!  The other problem is that the web, like html, is fault
>> tolernt, so that if you get it wrong your system will probably still work!
>> :)
>>
>> The challenge is to getting the language right so that it's easily
>> understood in the short spec doc., in particular so that people can get up
>> and running in under a day.  I'm going to put out a draft in the next few
>> days that is hopefully more understandable.
>>
>
> Section 11.5.1 of Draft 12 of the OpenID 2.0 spec recommends that OPs
> assign a unique url fragment to an OpenID url that changes when the OpenID
> changes ownership.
>

OpenID has quite a confused history in terms of how it identifies things.
Initially the original concept (Yadis) was based on Linked data (in
particular FOAF).  It kind of got taken over at IIW which was a mixed
blessing.  On the one had they had access to the likes of google yahoo and
microsoft, but on the other hand the identifiers got mixed up.  At one
point they wanted to use XRI to identify things, which was a proposed
alternative to the URI.  At this point XRI was voted against by both W3C
and OASIS, much to the disappointment of those that had bet on XRI as a
partial replacement to DNS (eg ibrokers).  OpenID is still surviving it's
turbulent history and the different identification schemes, it's future
seems forked with different people wanting to go in different directions.
IMHO this is the mixed blessing that happens when the bigcos. become
interested in an open technology.

URIs have had a more stable path, but not without it's own battles.  The
original web was very clearly a distributed documentation system.  HTTP was
designed to model documents, in particular HTML documents, but later
extended to other representations via the MIME type.

At this point, it's worth asking yourself, 'Is it worthwhile creating a
system to model documents?'.  The conclusion that I came to was a Yes,
based on how important documents have been and are in almost every
civilization of the last 5000 years.  The Web aka the Web of Documents,
seems a reasonable proposal.  However, right from the get go it was
designed to be more powerful than just documents.  It was designed to model
all sort of data.  The grand vision of the web is 'everything connected to
everything'.

The next question about documents you should ask is, 'Is it reasonable to
split documents into sections?'.  The answer I came to was also Yes.  This
is where the # notation was used, the so-called 'anchor'.  Now the aim was
always to get at data, so the idea was, 'lets put data in our documents'.
Given the first 2 evolutions, this is a natural fit.  So document#data was
used to point to data points.  Much like our passport could have a page
with your details on it, data could be represented on the web this way.

In essence this is the architecture of the world wide web.  Most web
programmers, do NOT know this history and motivation.  But it's a system
that scales and is about to start to scale massively in the next wave of
the web ie Linked Data.  This is what both webcredits and payswarm were
designed to take advantage of.  In a way it's a kind of secret weapon of
the web.  If # identifiers are not used in the way designed, the web will
still work, due to fault tolerance.  But when all the right technologies
that have been coming together for years, we can hopefully start to see
massive new waves on innovation.

I've done my best to paraphrase some of the motivations in Tim
Berners-Lee's book, "Weaving the Web".  I'd encourage anyone interested in
standards to read that as there are so many insights to be gained.


>
> an appended generation identifier is very different from having the URL
> refer to a big document (say, a roster) and the fragment point to a part of
> it (page and line of someone's listing in the roster.)
>

Correct


> The specification for fragments, Section 11.5.1 of Draft 12 of the OpenID
> 2.0 <http://tools.ietf.org/html/rfc3986#section-3.5> , pretty much says
> "anything goes" and delegates all fragment interpretation to specific
> schemes, so an identity scheme (even an OpenID 2.0 provider that uses
> fragments for more than generation differentiation) seems conformant.
>
Right, so HTTP has it's own meaning etc.


> I suggest that example identity strings in the short spec doc don't have
> fragments in them, also that the sentence where you state that any URL will
> do could affirm that when fragments are provided, the fragment is important
> and MUST NOT get stripped.
>
> How about http://tools.ietf.org/html/rfc3966#section-5.1.4 globally
> unique telephone numbers of well-known services for the examples? Is that
> too cute?
>

More than cute, in my view, getting this working with tel: is one of the
key challenges.  I guess one step at a time tho ...