Re: forms, direction, query, etc Š

hello henry.

On 2012-11-21 01:22 , "Henry Story" <henry.story@bblfish.net> wrote:
>In the thread on ISSUE-33 on pagination the mention of  SPARQL was there
>to help explain the relation between forms and queries using a well
>understood standard. The counter argument by Eric Wilde came
>in three parts
>1- forms are not queries to the user
>1. is simply wrong. It is quite obvious that forms are asking something
>of the user.
>     That answering a question can have additional impact ( such as
>answer yes to the question: "do you want to buy this book") does not deny
>that it is not a question

you're mincing words here. a form-based *question* is a simple thing that
does not require any agreement beyond that specific question. if i ask you
"which page of the query results do you want?", then all you can do is say
"42". the contract is simple.

a *query* is an expression in a rather complex language that operates on a
general-purpose metamodel and requires agreement on the metamodel, the
model that's used by the client and the server, and the query language
itself. it's a very different kind of contract.

there are of course some similarities, but saying that these two things
are the same is quite a stretch.

>2- forms are templates
>2. is true. Forms are templates but so are queries.

in one case you're asking a specific question, in the other one you're
executing an expression that requires agreement on metamodel, model, and
query language capabilities. very different things in terms of contract
complexity.

>3- semantics in forms is too complicated to implement
>     a-  client side
>     b-  server side
>3. complexity is a relative thing
>   a. the difficulty of implementing form understanding client side
>depends  on the complexity
>      of the query language - and that is as you point out not specified
>yet - it could be very simple.

yes, and the simplest language you can use is to use forms (and the web
itself with all the thriving form/template-based web services out there
seems to indicate that this doesn't seem to be such a bad design choice).
the most complex language choice for us is to use SPARQL (client-side!).
you seem to propose that there is something in the middle that does not
have the complexity of SPARQL, but yet is more powerful than simple forms.
you may be right, but i am not aware of such a language, and it is not our
WG's job to design such a language. but if there is such a language that
we can readily use, then we should consider it.

cheers,

dret.

Received on Friday, 23 November 2012 18:03:00 UTC