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 12:30:25 -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: <CCC7BDA9.BEB6%erik.wilde@emc.com>
hello henry.

On 2012-11-13 1:37 , "Henry Story" <henry.story@bblfish.net> wrote:
>I think you don't understand my point. I am not saying that one should
>use an RDF backend. I am saying that semantically those two queries are
>identical. One is readable by a human agent, an agent that can add very
>sophisticated contextual information to read a page in order to determine
>the semantics, the other is readable by robots which don't then need to
>learn how to add  context to the statements.

let's look at this in a very plain way: a form is nothing but a template
that clients are expected to fill out and return. maybe the form contents
are used for a query into something, maybe they are used to generate a new
resource from the form model, or maybe the form contents simply drive a
business process that doesn't easily translate to a read or write
operation on any database at all. the only thing that actually matters for
a form is the fact that it a way to capture "model-driven information"
from a client, and get it to a server. a form is state passed from server
to client, a filled out form is state passed from client to server driven
by the form.

since a form is simply a template a client is asked to populate, the
question is what model you have for that. HTML, for example, has created
its own simple model of a few form controls, and then most of the
capabilities lie in the fact that a publisher can freely arrange those
form controls in a form using HTML layout/labels and form field names.
thanks to scripting, these can even magically change at fill-out time and
for example generate new fields on the fly, when human users fill in
repeating fields and need more repeating fields.

where things get a bit more complicated is in the overall model of the
form. for example, when a field is repeating, and you have scripting to
generate new entries on the fly, the "model" is actually encoded in
scripting, so there's no machine-understandable way for clients to
understand how many repeating entries they can generate. XForms attempted
to change that and uses an approach where the "form model" is explicitly
communicated between the server and the client (in this case in XML). this
worked great, only that the release of XForms unfortunately came around
the same time as XML became uncool, and because of this (and some other
reasons as well) adoption was more limited than initially hoped for.
however, XForms are still used for a variety of applications, because of
their ability to clearly express the form model.

if your goal is to build an RDF-centric version of XForms, then you can do
that and XForms would be a useful thing to look at and see what worked
well, and what didn't. however, i'd say that doing this is outside of the
scope of the WG, and all we can hope for is to use existing specs. URI
Templates are different from XForms in that the model is much simpler that
XML or RDF; it's just a bunch of name/value pairs (with a couple of twists
such as repeating values and more, depending on the level
http://tools.ietf.org/html/rfc6570#section-1.2). but maybe that's better
than nothing and good enough to drive some of the things we'd like to do.

>By adding semantics to forms, you end up discovering that a web form
>is just equivalent to a query - but where the user is the agent answering.

i think your understanding of forms is limited here. forms do much more
than drive queries, and a form itself is nothing but a model template
that's made available by a server, so that a client can complete it
according to constraints, and then submit an instance of form data to the
server. driving some query is an important subset of form use cases, but
not all there is.


Received on Tuesday, 13 November 2012 17:31:38 UTC

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