Re: how to express HTML in Turtle as a hypermedia type

hello henry.

On 2013-03-28 01:34 , Henry Story wrote:
>> can you write me turtle that describes completely to a client how it has to implement HTML form submissions? i think (correct me if i am wrong) that your claim is that i can describe everything about a media type that needs to be know in RDF. assume i want to write a media type that defines the exact same submission rules for form fields that HTML defines, including the dance around GET/POST and multi-part submissions for file uploads and so forth. if you can write RDF that does that, and show me a generic RDF client with no knowledge of HTML than then is able to do everything that an HTML needs to do, then i rest my case.
> See Mark Baker's proposal.

this is not enough, this is just surface syntax. your claim is that just 
by GETting some RDF, a generic RDF client can learn how to behave 
according to a new set of rules (implement a new protocol), and all of 
this is completely represented by the RDF. because of this, you claim, 
we don't need to have any indication on the interaction level, because 
any RDF client will be able to do that at runtime on demand.

writing something like <rf:Form rf:method="POST"> is not different like 
writing something like <html:form method="POST">, on the surface. i 
guess that's pretty obvious. HTML requires that a client knows forms, or 
it will not know how to behave. your claim is that for RDForms, this is 
different, and any RDF client will be able to look at <rf:Form 
rf:method="POST"> and understand how to behave. could you please walk me 
through all the steps that will allow a generic RDF client to do this?

afaict, RDForms includes (by reference) the HTML forms processing rules, 
and does not even attempt to encode these in RDF. so what you have 
referred to, afaict, is not the definition of a media type, but a 
syntax, which critically relies (in this case) on the definition of HTML 
(which uses a different syntax, but now they share the same processing 
model).

don't get me wrong, i think it is perfectly fine to specify the 
processing model by documentation (or by reference to existing 
documentation) and just define a way how to represent data that is 
processed according to this processing model. but then there has to be 
some identifier that allows agents to talk about the processing models 
they know and implement. it's a conversation about supported 
vocabularies. your claim is that if i do not support RDForms and GET 
some RDF that uses it, i can learn, just by reading and interpreting 
RDF, what to do. where is that RDF? we need to look at that RDF 
*defining the media type by fully describing it in RDF*, and the web 
page you linked to simply has examples of *using the media type*.

cheers,

dret.

Received on Thursday, 28 March 2013 14:58:50 UTC