Re: The survey results are in and they look great

While the route you mentioned Ruben is the one I'd love to use (actually I 
already did), I'm afraid that the Hydra itself is not ready for non-RDF 
payloads.
This is the approach I used in my server/client API and unfortunately I had 
to break Hydra in some places.

I'm somehow sad that the discussion from very very abstract level before 
(that led us nowhere) got focused so much on low-level technical aspects 
like JavaScript specification to use, etc. While it's important (and 
probably to be decided by a let's say "project lead" which would need to 
appear to lead the development), discussion on the Promises (or maybe ES7 
async/await?) feels a bit premature.
Still we lack of the scope and features list that all clients should 
implement!

Few quick issues I had stumbled upon during my implementation attempts:
- clear connection between templated link and IRI template (really, I find 
it difficult with the current spec to connect each other)
- clear connection between IRI template and operations
- non-RDF and non-data payloads (i.e. documents, binaries, etc, hypermedia 
controls on HTTP level if any, etc.)
- collections and views in API description
- data structure description
- API description and in-bound hypermedia controls precedence
- filtering API hooks (for future pluggable specifications - I think this 
was the last agreement we reached)

As for the agnosticity of the client - to some degree I believe it's 
possible, but some places bound i.e. to view engines would need to be 
pluggable. I'm generally interested in building dynamic views from the hydra 
descriptions, thus angularJS and angularJS2 would need separate 
implementations of this part. Also few other places would need to be 
carefully designed like dependency injection (i.e. both angulars comes with 
their own).

These would be my 2 cents (are we gonna open a bank :)?)

Best

Karol

-----Oryginalna wiadomość----- 
From: Ruben Verborgh
Sent: Thursday, June 16, 2016 8:58 PM
To: Tomasz Pluskiewicz
Cc: public-hydra@w3.org
Subject: Re: The survey results are in and they look great

> I think that a Hydra client should be aware of RDF anyway.

If you use JSON-LD as a content type,
which is a great idea for JavaScript anyways,
there are two ways to look at it:
– treat the JSON-LD as JSON (no triples)
– treat the JSON-LD as RDF (triples)
(In the first case, you might need JSON-LD framing.)

So yes, even as an RDF fan myself,
I'd suggest that we should also look at the non-RDF route.
The most interesting libraries, however,
can actually offer both views: RDF (only) when you want it.

Ruben

PS My implementations have been RDF-based so far;
this is because I consider other content types than JSON-LD.

Received on Thursday, 16 June 2016 19:38:23 UTC