- From: Wilde, Erik <Erik.Wilde@emc.com>
- Date: Sun, 23 Jun 2013 23:28:32 -0400
- To: Andy Seaborne <andy@apache.org>
- CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
hello andy. On 2013-06-23 11:20 , "Andy Seaborne" <andy@apache.org> wrote: >JSON patch - it is actually quite similar in style. There is an >operation, a path and optionally value. XML patch is of the same style >- more complicated because the XML data model is more complicated. Both >use another language to describe the place in the document. The use of >xpath expressions means it isn't just XML; same for JSON paths on a >smaller scale. yes, you're right that patch operations need some way to identify what they're operating on, but that seems quite natural, since you're basically standardizing operators. but that doesn't mean that you cannot reuse the metamodel of what you're patching. you need to understand the XML Patch vocabulary (which uses XPath) to be able to apply a patch. but you can still use a standard XML parser to parse it, before you start processing it according to the rules of the vocabulary. >RDF patch is similar to an N-Quads file with an operation field added. >It also applies to a collection of RDF graphs. it may be that i am missing some RDF-specific issues here. i was generally commenting on the fact that it's useful to use the available toolbox of a metamodel (parsers, for example) to do the first step of implementing a patch processor. i think in JSON and XML, there would have been quite a bit of backlash against using non-JSON or non-XML syntax, but like i said, maybe there's something specifically different in RDF where this kind of design has its distinct advantages. cheers, dret.
Received on Monday, 24 June 2013 03:29:48 UTC