Re: [apps-discuss] draft-pbryan-zyp-json-pointer progress

[Julian Reschke <[e-mail]>]

On 2011-12-30 06:11, Paul C. Bryan wrote:
> On Thu, 2011-12-29 at 15:04 +0100, Julian Reschke wrote:
>
>> just checking: do we have a plan for the I18N issues?
>
> I believe the consensus is that a pointer should be Unicode; ramifications:
>
> 1. If it's a JSON string value, then JSON encoding applies.
> 2. If it's a URI fragment identifier, then URI percent-encoding applies.

+1

> The outstanding issue to address is cases where a member name contains
> reference token prefix "/" character(s). In light of this, using some
> sort of escape character makes the most sense; which character to use is
> the question. U+FFFD was mentioned. Any further thoughts?

Using a fixed replacement works for me. The alternative that was 
mentioned was a control character such as US (0x1f).

>> Also, while discussing this on the Jackrabbit mailing list, one
>> potential issue was brought up:
>>
>> If we do not special-case array addressing, a given pointer, such as
>>
>> /foo/bar/1
>>
>> can identify two different things, either foo.bar[1] or foo.bar.["1"].
>
> This topic has come up multiple times; it's true that .../1 is ambiguous
> until you resolve a pointer against a concrete JSON value. What's not
> been obvious to date is how identifying the type of value in the pointer
> is of use. I could imagine cases where you would want to create missing
> intermediate values while traversing a pointer, at which point .../1 is
> problematic as it would imply the creation of a sparse array. If there
> is a strong drive to identify types in pointers, I'm definitely
> interested in understanding the case further.

I agree with the analysis. Right now I can't provide a use case that 
would require removing the ambiguity, but I have the feeling that this 
will cause pain later on. Sorry for not having something more concrete...

>> Of course this is only a problem when looking at a pointer in isolation
>> (without knowing the object to apply it to), but I think it's worth
>> thinking about.
>>
>> Best regards, Julian
>>
>> PS: and yes, the downside of using brackets would be that we need to
>> escape more characters.
>
> Yes, ouch.
>
> Paul
>
> P.S. I'm planning on publishing new (APPSAWG) drafts for JSON Patch and
> JSON Pointer in the next few days, in time for review in the new year. :-)

Thanks!

Best regards, Julian