Define how multiple JSON pointers and line ranges can be combined together

[mitar]

So bytes range unit allows to specify multiple ranges like bytes=500-600,601-999. We mention in "URI Fragment Identifiers" section:

/api/document/1#json=/foo/bar/0,/foo/bar/1

But in fact we have not specified anywhere how multiple JSON pointers (nor line ranges) are combined together. Using comma might conflict with contents of individual JSON pointers.

We should clarify and define this for both range units.

[toomim]

Do you have a use-case for this? I'm not able to imagine one.

We can't use this patches, because it doesn't make sense to replace two discontiguous regions with a single value.

[toomim]

@mitar, do you have anything unresolved in this issue?

[mitar]

Yea, if you want to pull just a subset of fields from the related object. For example, a Linked JSON of:

{
  "foo": {"link": "http://example.com/foo#json=/field1,/field2"}
}

That would mean, when this gets expanded, that this is:

{
  "foo": {
    "field1": 1,
    "field2": 2
  }
}

And not the whole foo object.

[toomim]

Oh, so you're not actually concerned with patches as used for synchronization—you're trying to implement GraphQL-style queries here?

[mitar]

Its uses are the same as what other URI Fragment Identifiers are meant to support. Queries is one. But also highlighting/anchoring in the browser and things like that.

This issue is about completeness of that section. Other URI Fragment Identifiers support commas, ours do not.

[toomim]

I think there are deeper issues in using URI fragments for range queries— a fragment (anything starting with a #) is designed to not be seen by the server. So that means the server can't slice of a range for the user.

I suppose we should create a new issue for this.

[mitar]

I do no think this is a problem in this case. Because this embedding happens on the client in my view. So client fetches http://example.com/foo, but embeds just field1 and field2. If the server supports fetching a subset of state, then it can use that to also fetch from the server that, but I am not sure we have yet that in Braid.

[toomim]

You're right— I misunderstood what you wanted fragment identifiers for. Thanks for clarifying.

If the server supports fetching a subset of state, then it can use that to also fetch from the server that, but I am not sure we have yet that in Braid.

This is what a range request does already. Braid adds a Range Unit for JSON, which allows existing range requests to grab pieces of JSON out of a resource.

Ok, but overall, I'm still not understanding the use-case. You mention here that you can use this to pull out a subset of fields from a JSON object. I thought, by that, you meant to do a Range Request, but obviously I'm mistaken. I still don't understand the context of this. How is this information going to be used? Is this happening in a web browser? Is the web browser going to display it differently?

[mitar]

No, I think the JSON example I had is also obsolete with your example here. So we can ignore it.

So this issue is really just about being able to decide if it is reasonable to support multiple JSON pointers as an URI Web Fragment like https://tools.ietf.org/html/rfc5147 and https://tools.ietf.org/html/rfc7111 have. So the motivation really is here, that those other specs support multiple values, we do not. Do we want? For same reasons like they do.

[toomim]

Ok, thank you. This is much clarified. :)

[canadaduane]

@mitar Is the reference in RFC 7111 to multi-selections the relevant part here? https://tools.ietf.org/html/rfc7111#section-2.4

What are the "same reasons like they do"? (I apologize, I haven't read both specs in their entirety).

[mitar]

I think this (from the RFC 7111) is more relevant to "same reasons":

The fragment identifier consists of additional reference information to be interpreted by the client after the retrieval action has been successfully completed. The semantics of a fragment identifier is a property of the media type resulting from a retrieval action, regardless of the URI scheme used in the URI reference. Therefore, the format and interpretation of fragment identifiers is dependent on the media type of the retrieval result.

Also see RFC 5147:

Referring to specific parts of a resource can be very useful because it enables users and applications to create more specific references. Users can create references to the part they really are interested in or want to talk about, rather than always pointing to a complete resource. Even though it is suggested that fragment identification methods are specified in a media type's MIME registration (see [15]), many media types do not have fragment identification methods associated with them.

Fragment identifiers are only useful if supported by the client, because they are only interpreted by the client. Therefore, a new fragment identification method will require some time to be adopted by clients, and older clients will not support it. However, because the URI still works even if the fragment identifier is not supported (the resource is retrieved, but the fragment identifier is not interpreted), rapid adoption is not highly critical to ensure the success of a new fragment identification method.

Fragment identifiers for text/plain, as defined in this memo, make it possible to refer to specific parts of a text/plain MIME entity, using concepts of positions and ranges, which may be applied to characters and lines. Thus, text/plain fragment identifiers enable users to exchange information more specifically, thereby reducing the time and effort that is necessary to manually search for the relevant part of a text/plain MIME entity.

The text/plain format does not support the embedding of links, so in most environments, text/plain resources can only serve as targets for links, and not as sources. However, when combining the text/plain fragment identifiers specified in this memo with out-of-line linking mechanisms such as XLink [14], it becomes possible to "bind" link resources to text/plain resources and thereby "embed" links into text/plain resources. Thus, the text/plain fragment identifiers specified in this memo open a path for text/plain files to become bidirectionally navigable resources in hypermedia systems such as the Web.

Very interesting to me is the last paragraph, too.

[mitar]

To move discussion back to the multiple JSON pointers in the URI fragment, I would suggest we:

• document that fragment should be encoded like query string
• multiple URI fragments should be then of form #json=/foo/bar/0&json=/foo/bar/1