W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: ldp-ISSUE-33 (pagination): how to structure functionality

From: Wilde, Erik <Erik.Wilde@emc.com>
Date: Tue, 13 Nov 2012 17:47:58 -0500
To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
CC: "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>, Henry Story <henry.story@bblfish.net>
Message-ID: <CCC80A86.BF61%erik.wilde@emc.com>
hello henry.

i'll refrain from further emails after this one unless others think this
conversation is useful.

>Let us get back on the topic of pagination. The following html form would
>as a simple pagination form for a collection <> .
><FORM action="p?" method="post">
> <P>
> page number:  <INPUT type="text" name="page"><BR>
> entries per page: <INPUT type="text" name="pageSz"><BR>
> <BUTTON name="Get answers" value="submit" type="submit"></BUTTON>
>Are you with me here?

this is the service surface and if you used standardized link relations,
no form is required an RFC5005 would happily guide all interactions. let's
assume you don't want this. if your service documented what the field
names mean, then this would be a proper service.

>So let's transform the above form into a SPARQL query
>SELECT ?page ?pageSz
>TO <p>
>  [] a PaginationSlice;
>     :pageNumber ?page;
>     :entriesPerPage ?pageSz .

you cannot "transform a form into a SPARQL query." a form is a template
that defines what kind of input a service expects. clients are expected to
fill out the template, taking into account all constraints that are
defined as part of the service. servers validate the data, and if the
request validates the pre-conditions, it is executed. this can mean that
(part of the) form data is used to populate a query. it can also drive
code that has no query component to it whatsoever, and simply computes the
service's response.

>>>Those are UI models, not semantic models. They don't make the context
>>> clear.
>>> This works for humans, not for robots.
>> these are service models, not UI models. you need to understand the book
>> ordering service to understand what it means to select "yes/no" from the
>> "yes/no" question, right?
>Later when we have worked out the details we can get the RDFa people to
>work out 
>some how to markup a real form neatly and beautifully so that the html
>form and the
>query can be nicely merged together... For the moment I am just
>describing the
>general idea. We can leave UI for later, when the model is clear, and
>work with 
>psychologists to find out what people find most natural.

personally speaking, for the immediate WG goals, there's too much "and
yes, we need to fill in all those blank spots" in here. all i have been
trying to do is explaining how REST approaches this problem, and how
existing standards could be used to prevent us from reinventing some

>>>yes. But not just XForms. SPARQL is a form language already. So it would
>>> be interesting to see what is missing.
>> how is SPARQL a form language? it is a query language.
>Because a form is just a query to the user!

a form is a template with a service-defined model. a query languages
queries any kind of data that's managed based on some general-purpose
metamodel. these are different things. you might have visions of how forms
and/or query languages could be changed or designed to completely change
how things are currently working, but going back to ISSUE-33, the question
was how to expose pagination affordances in a more general way, and web
architecture and existing standards give us a pretty solid starting point.


Received on Tuesday, 13 November 2012 22:48:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:33 UTC