couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: JSON Patch Internet Draft 01
Date Thu, 09 Jun 2011 21:56:43 GMT
> In the JSON Pointer RFC it states that path components SHOULD be URI
> encoded and that "/" MUST BE uri encoded but in the algorithm
> description for moving the reference pointer there's no language on
> URI-decoding the path component. Also I have no idea how this would
> play with utf-8 or other unicode representations. Perhaps just
> escaping any "/' characters would be enough here though that could get
> confusing as it'd be "\\/" in all the examples.
> Okay, I think I'll write-up process for encoding and decoding so as to
> clarify. In a nutshell, to decode, break into tokens using "/" separator,
> then URL-decode each fragment. Make sense?

My bigger concern is what to do about unicode in JSON strings though.
URI encoding is specified at the byte level where as JSON strings are
specified as a list of "any unicode character". Plus this is affected
by internal representation of unicode. The issue is to figure out how
to make the JSON diff not have to do tricky things that would need to
extend some major definitions of JSON.

This is why I was toying with the idea of using an escaped solidus
character at the application level. By not converting characters we
neatly avoid the issue of how to transform various types of unicode
representations into other types of unicode representations in this
spec. The only downfall of this method is that at the transport layer
(ie, as JSON) the application level escape reads as "\\/" or "\\//".

Another method (though unatractively verbose) would be to list the
path as an array of strings and or integers. Which would also nicely
disambiguate for cases like {"1": "some stuff"}. Also that brings up
an error scenario that might need to be spec'd.

Paul Davis

View raw message