incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul C. Bryan" <>
Subject Re: JSON Patch Internet Draft 01
Date Thu, 09 Jun 2011 23:28:16 GMT
On Thu, 2011-06-09 at 17:56 -0400, Paul Davis wrote:

> > 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

Ah, I see. A couple of possibilities come to mind (which I note may be

1. We specify URL encoding is on UTF-8 encoding of the token.

2. We relax the URL encoding requirement in JSON Pointer (where it is
not used in the fragment) from SHOULD to MAY; encoding of "/" remains a

I have to admit the unattractively verbose has its benefits as you
point-out, but will be killer if we try to use it in a fragment—which
remains a strong goal of JSON Pointer.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message