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

On 28 April 2012 09:22, Michiel de Jong <michiel@unhosted.org> wrote:

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

interop is the primary consideration

ie for the web to be the 'intersection of information spaces'

anyone that follows web arch will interop straight off the bat, even those
that do not can make their stuff interop as the web is a universal system


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

should you use <br> or <br/> in an document?  Chances are either will work,
but only one will generally pass a validator.

similarly with webcredits if you follow the spec and know how to program
the web you'll 100% guaranteed interop

but if you 'think' you know how to program the web, and make mistakes
likely you'll still be ok in a local environment


>
> 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'.
>

having a convention that amount field missing to be equal to an arbitrary
non zero value seems quite a contrived edge case

in theory i should make a best practices doc and maybe a validation and/or
test suites



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

URIs are designed for compatibility ... they are the fundamental axiom of
the web, and it's value proposition.  Misuse URIs on the web and you are
lost.