Subject: [apps-discuss] #10: json-pointer fragment identifiers

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Jul 2012 17:29:34 +1000

<http://trac.tools.ietf.org/wg/appsawg/trac/ticket/10>

This is actually about pointer; there isn't any reference to fragment identifers in json-patch any more.

I think there are three ways we could go here:

1) Make json-pointer the fragment identifier syntax for application/json. This would require updating the media type registration.

2) Explain how json-pointer could be made the fragment identifier syntax for *your* media type, upon specification. This would require a small amount of editorial work.

3) Remove any reference to use of json-pointer as a fragment identifier syntax. This would require a bit of editorial work.

Thoughts? FWIW, my .02 is that #2 seems eminently reasonable.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 3 Jul 2012 17:40:57 +1000

> 1) Make json-pointer the fragment identifier syntax for
> application/json. This would require updating the media type
> registration.
> 
> 2) Explain how json-pointer could be made the fragment identifier
> syntax for *your* media type, upon specification. This would require a
> small amount of editorial work.
> 
> 3) Remove any reference to use of json-pointer as a fragment identifier
> syntax. This would require a bit of editorial work.
> 
> 

#1 & #2
There was some concern that making JSON pointer THE fragment id for application/json prevented more sophisticated stuff later. However, a JSON pointer can only start with "/" so there should be room to add semantics to other fragments later.

--
James Manger

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jul 2012 09:43:20 +0200

> 1) Make json-pointer the fragment identifier syntax for application/json. This would require updating the media type registration.

I'd be unhappy about that, because so far we don't have a solid use 
case; and the syntax leaves no extension points.

> 2) Explain how json-pointer could be made the fragment identifier syntax for *your* media type, upon specification. This would require a small amount of editorial work.

That would work for me, as long as it's phrased in a way that makes it 
totally clear that it doesn't apply to application/json.

> 3) Remove any reference to use of json-pointer as a fragment identifier syntax. This would require a bit of editorial work.

That would be my preference.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jul 2012 09:46:51 +0200

> There was some concern that making JSON pointer THE fragment id for application/json prevented more sophisticated stuff later. However, a JSON pointer can only start with "/" so there should be roo…

Good point, except for the "empty pointer" case...

May I ask about what use case you are considering?

Given the fact that JSON-Pointer is bleeding edge and escaping remains 
to be ugly I'm really reluctant to bake that into the "application/json" 
media type until it's clear why.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Jul 2012 17:55:20 +1000

One other option -- we can decouple the decision and add json-pointer as a fragid syntax for application/json later.

Cheers,

On 03/07/2012, at 5:43 PM, Julian Reschke wrote:

> I'd be unhappy about that, because so far we don't have a solid use case; and the syntax leaves no extension points.
> 
> That would work for me, as long as it's phrased in a way that makes it totally clear that it doesn't apply to application/json.
>

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 3 Jul 2012 18:06:40 +1000

> >> This is actually about pointer; there isn't any reference to
> fragment
> >> identifers in json-patch any more.
> >>
> > There was some concern that making JSON pointer THE fragment id for
> application/json prevented more sophisticated stuff later. However, a
> JSON pointer can only start with "/" so there should be room to add
> semantics to other fragments later.
> 

No crucial use cases yet. Picking the right key from a JSON Web Key value is a possible use [draft-ietf-jose-json-web-key].

> media type until it's clear why.

A hassle with #2 is that most/many JSON formats use application/json even though defining a more specific media type might be better. If any of those want to use JSON pointer for their URIs & documents (or they just go ahead and use it) it already starts polluting any future official fragment format.

--
James Manger

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jul 2012 10:07:35 +0200

On 2012-07-03 09:55, Mark Nottingham wrote:
> ...

Of course. My main concern is about doing it as a "side effect" instead 
of clearly updating RFC 4627.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jul 2012 10:17:19 +0200

> No crucial use cases yet. Picking the right key from a JSON Web Key value is a possible use [draft-ietf-jose-json-web-key].

It seems that you then would have to rely on array indices, right?

Best regards, Julian

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 03 Jul 2012 19:36:26 +0900

On 2012/07/03 17:07, Julian Reschke wrote:
>> One other option -- we can decouple the decision and add json-pointer
>> as a fragid syntax for application/json later.

> of clearly updating RFC 4627.

Of course the draft would say "updates RFC 4627". Or is that not what 
you mean?

If the escaping syntax is ugly, but we tried very hard and didn't find 
anything better, then the chance that somebody else will find something 
better is low.

And "waiting for later" often means "waiting for never".

So I think we should just go ahead and define it.

Regards,   Martin.