search

braid-org / braid-spec

Working area for Braid extensions to HTTP
https://braid.org
Other
237 stars 16 forks source link

JSON - XML conversion #4

Closed mitar closed 5 years ago

mitar commented 5 years ago

In draft-xx-httpbis-braid-patch-00.txt you state:

XML files have an isomorphic partial ordering with JSON files. You could conceivably re-use a JSON synchronizer on an XML file by converting the XML to JSON, merging the JSON, and then converting the result back when necessary.

That is not true. XML files without additional schema do not have enough information to do this conversion in general. For example:

<div>
  <p>Foo</p>
</div>

How should this be converted to JSON? There is no standard way. Moreover, it is unclear if p should be a list of p elements or just one. You could always convert to lists, but then also your patch should be aware of that. So if you convert to JSON and try to apply a path specification to it, it might not work.

I am not sure why this speculation/suggestion does even have to be in the spec though? It does not add much and it could be more suitable for some other library, which uses this trick (if it really works) for its implementation, but does not have to be really specified in the spec?

mitar commented 5 years ago

Or at least, I think you should find some reference to reference the claim that "XML files have an isomorphic partial ordering with JSON files". So maybe see this issue as "reference needed". :-)

toomim commented 5 years ago

XML files have an isomorphic partial ordering with JSON files. You could conceivably re-use a JSON synchronizer on an XML file by converting the XML to JSON, merging the JSON, and then converting the result back when necessary.

That is not true. XML files without additional schema do not have enough information to do this conversion in general.

Maybe this wasn't clear—we aren't converting JSON to XML. We are simply saying that these file formats can re-use the same synchronizer.

How should this be converted to JSON? There is no standard way. Moreover, it is unclear if p should be a list of p elements or just one.

The choice of whether p should be a list or an atom would be made by the parser, aka selector.

I am not sure why this speculation/suggestion does even have to be in the spec though? It does not add much and it could be more suitable for some other library, which uses this trick (if it really works) for its implementation, but does not have to be really specified in the spec?

This example is in the spec to illustrate that you can re-use a synchronizer across multiple data formats. Is that unclear? Is there a better way to explain that?

mitar commented 5 years ago

Hm, yes, that was unclear. In this case then I would suggest that maybe we do not even go into this. Probably this will be resolved by splitting spec into two specs as we discussed. Because to me it feels that the fact that synchronizers can be reused and when is something which really depends on synchronizer itself. And because we are not defining/standardizing any of them in any of these specs I think it is out of the scope to discuss how to reuse them. Because it is hard to argue about that. Does this imaginary synchronizer really work or does not work on both XML and JSON? We do not know and cannot know.

So I would split merge types out and then leave out the fact that multiple merge types can potentially work on different data formats. Or, simply claim that this is true, but for which combinations it is true depends on a synchronizer. We just have to specify how merge type is defined. And how a patch defines which merge type is used.

mitar commented 5 years ago

So my proposed action item here is that we remove this discussion about XML - JSON correspondence and leave for other places to note which synchronizers can work with which parse types.