Re: Why JSON-LD? (was: Re: Agenda: Web Payments Telecon - Friday, February 10th, 2012)

On Thu, Feb 9, 2012 at 7:20 PM, Manu Sporny
<msporny@digitalbazaar.com>wrote:The wire-level format for data
transmitted within Payswarm is JSON

> (Javascript Object Notation.) Invariant key/value pairs and key names
>>  have been selected to conform with JSON-LD, and a schema document
>> parseable with JSON-LD tools has been registered with purl.org
>> <http://purl.org>.
>>
>
> Hmmm, that's not quite what's going on here.


No? I didn't see anything in your response that contradicts my
dispassionate summary.


the three main reasons we use JSON-LD [are]:
>
> * Web-native data model (IRIs as identifiers - good for the Web)
> * Works with existing JSON tools (good for Web developers)
> * Decentralized Extensibility (good for innovation)
>
> JSON doesn't fit the first and last bullet point well. The other Linked
> Data formats don't fit the second bullet point well.
>

I'm not suggesting you stop any of that, or change the meat of the
wire-level protocols you are proposing at all (not here, anyway. I reserve
the right to make such suggestions in the future)

What I'm saying is, requiring your audience to drink the kool-aid is going
to make a lot of them mosey towards the exits. By introducing JSON-LD as a
given (it's JSON, and it's conformant with JSON-LD, which BY IMPLICATION is
worth looking into, but that's not why I called this meeting) you can *show
instead of tell* what makes JSON-LD the best thing since the convention of
capitalizing abbreviations.


> JSON-LD uses IRIs for identifiers, which means that it supports
> follow-your-nose (the ability to start at one document and discover
> other resources by de-referencing links to other documents). This sort
> of dereferencing is at the heart of decentralized systems and is used
> extensively in the PaySwarm specs.
>

That's great! So, tell us that *PaySwarm* uses IRIs for identifiers, which
means that it supports follow-your-nose (the ability to start at one
document and discover other resources by de-referencing links to other
documents), and let us agree (or dispute) the coolness of that, okay? And
if we think that's as cool as you think it is, we may want to set up other
protocols the same way, and we'll come back to JSON-LD (As used in
PaySwarm!)


> JSON-LD was designed to be compatible with the existing JSON toolchains
> and layer on top of regular JSON documents if necessary. It was designed
> to give Web developers access to Linked Data without requiring them to
> learn a great deal about it. JSON-LD is basically the power of a
> graph-based data structure, expressed as simple key-value pairs.
>

That's nice. And irrelevant.


> Since JSON-LD uses IRIs for object properties, you can expand the
> functionality of a JSON-LD document without worrying about property name
> clashes or if the system will accidentally use the term you use in the
> future. JSON-LD provides a future-proof mechanism for expanding the
> functionality of the objects used in PaySwarm (things like Assets,
> Transfers, Transactions, Listings, and Contracts).
>

requiring facility for "expanding the functionality" of objects used in a
payment infrasturcture is frightening. It's general, so you want to have
the equivalent of pointer-to-void types in there for the things that can
change, sure, but also the objects should be restricted to the things that
make sense

All of these come into play when you want to innovate on top of the
> platform - it's just something that regular JSON does not do a very good
> job at.


and that's why you're using JSON-LD. Show, don't tell (he tells.)


> Yes, you can quarantine a part of a JSON document off and state
> that "any extensibility stuff goes here", but that's not a very elegant
> solution. JSON-LD is elegant in that it allows you to extend the
> document where it makes the most amount of sense for your application.
>


so if I write an application to rip someone off, I can extend the document
in ways that will make sense for me to do that? I can extend the document
in ways that allow XSS attacks? I can extend the document to cause
distributed denial of service attacks against my hapless victim who
suddenly has to field a billion requests for a nonexistent context
definition?




> It allows innovation at the edges and if the innovation becomes
> mainstream, it allows that innovation to be absorbed into the
> standardized system without breaking backwards-compatibility with the
> documents that are already out there.
>
> At this point, you are either nodding your head in agreement, or you
> don't think what I'm saying makes one bit of sense. In the latter case,
>

no, neither. And furthermore, I do not wish to join the church of JSON-LD
at this time.