RE: Reinventing Web applications

On 23 Jun 2014 at 16:50, Martynas Jusevičius wrote:
> On Sun, Jun 22, 2014 at 11:26 PM, Markus Lanthaler wrote:
>> On 21 Jun 2014 at 15:36, Martynas Jusevičius wrote:
>>> First we want to specify the standard way triplestore-based Linked
>>> Data servers work, as this goal is much more realistic in our view.
>> 
>> How can you possible standardize that if you don't limit yourself
>> to very simple models such as CRUD applications? Creating a
>> resource in a triple store and ordering a product are, IMO, two
>> completely different things. The client acting on behalf of the
>> user doesn't care at all about the former but cares a lot about the
>> latter.
> 
> We do limit ourselves to simple container/item models and CRUD
> operations. That is why HTTP and REST have been successful.

Really? That's new to me. REST is definitely not about CRUD.


> What do you think about LDP? They are trying to do a similar thing,
> but in a wrong way.

It may be that I don't fully understand LDP but AFAICT it's nothing else than RDFied AtomPub.


> And how exactly is creating a resource different from ordering a
> product? Don't our actions on Web services eventually translate to
> state changes?

Wouldn't you like to know whether your credit card gets charged if you create an order resource?


> If end-user clicks a button on a form, and that action creates an
> order in RDF, is that simply creating a resource or ordering a
> product? In my world it's both.

If the form has a "click here" button, the user wouldn't know. If the button says "store order", the user wouldn't expect that its credit card gets charged. If the button says "Confirm order" or something similar he would expect that his credit card gets charged and assumes that the products will be delivered shortly thereafter.

In the EU there are now laws [1] that require websites to use very explicit labels on those buttons so that users do understand what consequences a click has:

    If placing an order entails activating a button or a similar
    function, the button or similar function shall be labelled in an
    easily legible manner only with the words ‘order with obligation
    to pay’ or a corresponding unambiguous formulation indicating that
    placing the order entails an obligation to pay the trader


>> Pagination is an interesting example. I had a look at the spec at
>> 
>>    https://github.com/Graphity/graphity-browser/wiki/Linked-Data-Processor-specification
>>
>> You define how to describe it to the server but don't specify at all
>> how the data is being exposed. All you say is
>> 
>>     Page description SHOULD include descriptions of the container
>>     and previous/next pages, as required by HATEOS [REST].
>>
>> Now, this is very vague and wouldn't be enough to build interoperable
>> systems. Would this be something where Hydra could help?
> 
> The implementation is currently ahead of the specification. That's why
> I wanted to bounce some ideas and then develop the spec further.

Fair enough. So, what is the implementation doing?


> In the long term, yes. In the short term, we want to be able to manage
> our applications as data (plus some UI templates) instead of having to
> write imperative code. That brings substantial time and cost savings.
> 
>> Yeah, makes sense but it also makes it more a software
>> specification than a Web specification. Why did you decide to start
>> the effort to standardize this now? Are other people implementing
>> processors which do not fully interoperate with yours?
> 
> I'm not sure I know where the line goes between a software
> specification and a Web specification. I'm thinking XSLT, RDF,
> SPARQL, LDP -- they're all simply W3C specs to me.

It's certainly a fuzzy line but for me a Web specification is something that is exposed on the Web and used by different independent systems without central coordination. This is not really the case here AFAICT. The description will be used by the processor (the server) internally. It uses it to know how to server the data it has. The client, AFAICT, doesn't see this description (and doesn't need to see it).


> We want to standardize to show Web applications can be designed in a
> declarative way. We're not creating a new technology here, we're just
> filing in the gaps between existing ones.

That's great and certainly needed to advance this space. I'm just wondering whether concentrating on implementations isn't more productive in that case. Standardization is slow. Really slow. It doesn't have much value by itself. It is just there to ensure interoperability between different systems. I'm not entirely convinced yet that such interoperability is needed... and even if it is, I'm not sure a formal specification is the best way to achieve it... Perhaps a comprehensive test suite might be a better choice. I don't know. In any case, I wish you good luck. I will try to follow your progress. If there's anything I can do to help or if you see opportunities for collaborations between the Declarative Apps and the Hydra CG, let me know. I think it would be very valuable to try to augment your platform with Hydra support as soon as Hydra is stable because, as far as I understood, your platform makes it very easy to set up an API (as long as the backend is a triple store).


Thanks for the very interesting discussion,
Markus


[1] http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2011:304:0064:0088:EN:PDF



--
Markus Lanthaler
@markuslanthaler

Received on Monday, 23 June 2014 20:56:40 UTC