Re: Section 4: LDPR/non-LDPR formal definitions

hello richard.

On 2013-03-23 10:47 , Richard Cyganiak wrote:
> I'm not sure what point you are trying to get across. I didn't say anything that assumes or requires that LDP clients are “full-blown RDF processing entities”. In fact, I have no idea what a
> “full-blown RDF processing entity” is.

the point i am trying to get across is that protocols have processing 
models. what do you need to do/know to use that protocol? my example was 
about XSD processing, but that is a different metamodel world. in RDF, 
something similar to that is doing inferences. if that's something 
that's *required* to be able to use the protocol, we have very different 
requirements for implementation than if inferencing is something that 
implementations may do (for whatever reason), but they don't have to.

in my mind, the success of JSON (and reduced popularity of XML as a 
direct result of this) had two major reasons:

- processing model: JSON is pretty much as easy as it gets, writing a 
JSON parser is simple, and there are no additional required specs you 
need to get right (such as the dreaded XML namespaces).

- model impedance: JSON is just a more natural match to programming 
language data structures than XML, so developers like the fact that data 
binding is easier, or basically not necessary at all.

there is nothing that can be done about the second part once you start 
building something on a certain metamodel. the first part, though, is 
under our control, and the LDP design can make this part harder, or 
easier. i hope this explanation is a bit better to understand.

thanks and cheers,

dret.

Received on Saturday, 23 March 2013 23:18:51 UTC