Re: [apps-discuss] JSON Pointer syntax

[James M Snell <[e-mail]>]

On Thu, Sep 20, 2012 at 8:13 AM, Julian Reschke <[e-mail]>wrote:

>
>>         Yes, it does consider:
>>
>>         { "alice" : { "bob" : [ 10, 20, 30] } }
>>
>>
>>         Let us imagine we have code that is stepping through each
>>         element of an
>>         array using an index i. The path looks like  alice.bob.i
>>
>>
Huh? If we're iterating through this using JavaScript code it would be
something like

  for (i in m.alice.bob)
    print(m.alice.bob[i]

If I was going to use a JSON Pointer to iterate through, it would look like

  for (i in m.alice.bob)
    print(eval_pointer( "m.alice.bob." + i ))


         Iterating the loop produces 10, 20, 30
>>
>>         When evaluating that expression in a scripting language or such
>>         we have
>>         alice and bob which are tag names and we have i which is a bound
>>         variable being used as an index. That leads to confusion.
>>
>>
I'm sorry, but there is no confusion when the code example actually makes
sense. No disrespect intended, but the example you give here, Phil, does
not appear to make much sense.


>         Now imagine that mallet knows that the index variable used is i,
>> she
>>         creates the following message:
>>
>>
>>         { "alice" : { "bob" : [ 10, 20, 30] , "i" : 42 } }
>>
>>         Depending on the implementation the iteration may now produce
>>         10, 20, 30
>>         as before or 42 or even 42, 42, 42.
>>
>
> How so? There's is only one object named "alice.bob" here, and it is an
> array. There's also "alice.i", but how does that matter?
>
>
The full set of valid JSON Pointers I see in this example are:

  /alice
  /alice/bob
  /alice/bob/0
  /alice/bob/1
  /alice/bob/2
  /alice/i

Which in dot notation, of course, would be:

  alice
  alice.bob
  alice.bob.0
  alice.bob.1
  alice.bob.2
  alice.i

I see absolutely no confusion here.


>  [snip]
>
>> I am asking questions of interpretation here and your response is always
>> 'go read the spec'. Well that is the whole issue, the spec is not clear
>> and it cannot be clear on this issue unless it raises it and addresses
>> it as a specific case.
>>
>> If people can't explain how a spec should be interpreted then the spec
>> fails.
>>
>>
Yes.. and again, no disrespect intended here Phil, but I think the issue at
hand right now is that, so far, none of the examples and feedback you have
provided, thus far, have made any sense at all.


> [snip]
>
>          No, it is RESERVED as in do not use it after the query.
>>
>>         We are not talking about a change to the HTTP URL spec here. So
>>         we MUST
>>         NOT use that character. It is out of bounds.
>>
>>
>>     BS. Nobody is proposing to change the URI syntax, which happens to
>> say:
>>
>>         query       = *( pchar / "/" / "?" )
>>
>>
>> It goes on to say:
>>
>> The characters slash ("/") and question mark ("?") may represent data
>> within the query component. Beware that some older, erroneous
>> implementations may not handle such data correctly when it is used as
>> the base URI for relative references (Section 5.1
>> <http://greenbytes.de/tech/**webdav/rfc3986.html#base-uri<http://greenbytes.de/tech/webdav/rfc3986.html#base-uri>
>> >)**, apparently
>>
>> because they fail to distinguish query data from path data when looking
>> for hierarchical separators. However, as query components are often used
>> to carry identifying information in the form of "key=value" pairs and
>> one frequently used value is a reference to another URI, it is sometimes
>> better for usability to avoid percent-encoding those characters.
>>
>> This would not be something I would see as critical if there was not
>> another choice here.
>>
>
> I don't see it as critical.
>
>
>  Probably the safest approach is to permit either separator to be used in
>> the path expression and make them interchangeable which is what we did
>> with " and '.
>>
>
> I don't believe that allowing two different notations is actually helpful.
>
>
+1 .. Pick One.

>
>  That still leaves the question of what to do with []. It looks like they
>> should be safe but it is something I would want to see tested.
>>
>
> That would be relevant if JSON Pointer actually needed them. They are in
> RFC 3986's gen-delims, so strict URI parsers are likely to be unhappy when
> seeing them in unescaped form (in the wrong place).
>
>
I have run into a number of very real issues in various places with the use
of errant square brackets in query string parameters and fragment
identifiers. 3986 is actually quite clear on the fact that square brackets
are ONLY allowed when delimiting IPv6 addresses.

Specifically, section 3.2.2:

   A host identified by an Internet Protocol literal address, version 6
   [RFC3513] or later, is distinguished by enclosing the IP literal
   within square brackets ("[" and "]").  This is the only place where
   square bracket characters are allowed in the URI syntax.

I'll say again that I personally prefer the JavaScript notation, even with
square brackets and I don't generally see a problem with escaping those
within the URI. But the square brackets are not strictly required to make
things work. The existing / delimited syntax does work in practice and it's
simple to implement.

- James


> Best regards, Julian
>
>
> Best regards, Julian
>
> ______________________________**_________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>