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

On Tue, Apr 24, 2012 at 6:14 PM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
> The fields source and designation were taken reused the payswarm ecommerce
> vocab.  The idea is for it to be anyURI (ie anything at all).

hold on, then how do you know if apps will be interoperable? you don't
care about that?

> 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!

everybody uses the # to mean document fragment, and the definition of
a URL-with-fragment as both the document and its topic breaks
machine-readability. It's fine among humans who can interpret from the
context that 'A fat biography' can be a word joke. Unfortunately I am
unable to develop applications that understand word jokes. That's why,
although I'm aware that what you describe there is what some prominent
w3c engineers propose, I would still vote against it in the context of
webcredits.

Having said that, a more important point i think is whether or not the
webcredit spec says anything about the meaning of a webcredit. Is it
to be interpreted by the app as some sort of 'credit' or should its
apparent usefulness for that be interpreted as out-of-scope? Do we
only want all apps to use the same syntax, regardless of whether they
interpret the meaning in incompatible ways? I think that would be
useless and silly.

> 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!
> :)

define 'work'. all apps will still be able to store and reproduce the
literal webcredits, and even to partially display their content to the
user. but they won't be able to interpret them. the fault-tolerance of
html comes from the fact that it's human-readable documents. for
machine-readable documents, an error is an error. i want the
webcredits spec to forbid word jokes and to define exactly when a
webcredit document describes a real-world credit, and if so, between
which parties, and with which amount and in which currency, and when
it doesn't.

imagine two apps. one says 'if the amount field is missing, that means
the amount is 1'.
the other says 'if the amount field is missing, that means the amount is 0'.

now you and i start exchanging webcredits. after some time, i claim
that you owe me money (becuase that's what i see in my app), and you
claim that i owe you money (because that's what you see in your app).
both apps are webcredits-compliant in the fault-tolerant way you seem
to be proposing. yet the apps are incompatible.

why propose a spec that doesn't lead to compatibility?

Received on Saturday, 28 April 2012 07:22:55 UTC