- From: <karol.szczepanski@gmail.com>
- Date: Mon, 12 Oct 2015 08:56:37 +0200
- To: <public-hydra@w3.org>
Hi Markus I fully support view approach. I suggested view-like approach in Februrary (http://lists.w3.org/Archives/Public/public-hydra/2015Feb/0009.html), similar document-like approach appeared before several times as well. Still, your example has still several flaws and I think we'll end up with a conclusion that while served indeed provides a view, but the view is crafted by the client. We'll end up with very basic but still covering 95% of use cases "query like" hydra platform that will allow client to do simple operations we all know from applications we develop: - show first page of the collection - currently covered - show numbered pager - currently client wouldn't know how many pages there are - show next/prev - currently covered - show next/prev bucket of pages - currently not covered - provide sorting details - currently client doesn't know anything about that - it is given some resources in unspecified order - provide basic filtering details - freetextQuery is somehow solution here, but I don't see it anyway connected to the paging and collection These should come from the client with server defaults if nothing is explicitly expressed. I've started a proof of concept of a angularJS application that would user hydra API Documentation provided by my URSA tool to build a generic on-the-fly generated views and will provide feedback on issues experienced. This should give a hint of what might be needed so developers will know how to proceed with that. Best Karol
Received on Monday, 12 October 2015 06:57:11 UTC