Linking into a JSON doc with anchor tag or metadata

[mitar]

With allowing anchor to be JSON pointer or something like that?

[toomim]

You could specify a subsection of a JSON document with metadata, as exemplified here: https://github.com/braid-work/braid-spec/blob/master/draft-xx-httpbis-linked-json-00.txt#L103

[mitar]

I do not think that example is normative, no? This is example. Not standardized how it should be done.

[toomim]

You could propose a standard for that separately, if you want. We can't standardize all metadata within the Linked JSON spec, so I don't know why we'd want to standardize any of it.

[mitar]

But if you are already having URLs, why not also simply making anchor value in URLs be JSON pointer or something like that? So not sure why this should be not specified.

Also, standardizing on some of metadata fields would be useful. I mean, this is the whole point why we are making a standard. That if multiple people want to use something they know how to do it so that it is compatible with others. So we should identify which of those use cases we are about or we find common enough and standardize them.

[toomim]

I'm closing this issue, but feel free to re-open it if you would like to continue the conversation.

Edit: oops, I seem to have done this right when you posted a new comment. Unclosing.

[toomim]

You could do this with an anchor, like json-ref does, or with metadata. If we specify an anchor format, then we'll have to use this one format for all time. If we use metadata, then different people could define different formats. I personally anticipate using GraphQL for this kind of thing, but I know that other people have written specs where you /select/a/path/into/json/with/slashes, and others use.regular["json"].subscript["notation"].

Personally, I didn't think we needed to make this decision right here, right now. We can minimize the number of decisions we are making in this spec, and then add more stuff later. I don't have any use cases where I'm actually linking deeply into JSON. In your code, this standard might be able to save an extra .foo.bar in a few places. But it doesn't come up that often in the code I've written.

[mitar]

I think as discussed here that you should decide if you want to support just linking or also embedding/transclusion. If it is just linking, then I agree that linking to a resource is enough. Even if, BTW, HTML does support deep-linking with standard way.

If you want to define also embedding/transclusion then defining a standard way to describe this is important. You do not have to prescribe it fully, but describe how it should be done. For example, maybe describe that deep-linking should always be done with:

{
  "link": <url>,
  "selector": "some selector",
  "selector-type": "selector type",
}

And then we can see that we can use same selector types (or parser types) both here and in the patch format. :-) And same selectors here and there. It is the same thing. And why not standardize how you do that, but standardize it in extendable format?

[mitar]

From here:

Can you give an example of a problem that this would cause with an implementation? Is there something an implementation cannot do if we do not separate the concept of a "link" from a "transclusion"?

I think the point here is that if we are defining a common format like this, I do not see why not define standard behavior for main types of behaviors we want to support (linking and transclusion). The point of the standard is to make compatible implementations.

[toomim]

Ok, so it sounds like you don't have an example where we need this.

If we don't have any examples where we need a spec, then let's leave the spec out. Since we don't have any examples of implementations that need to distinguish between a link and a transclusion, I think it's premature to put that into the spec. None of the implementations I've written have needed this to be distinguished.

[mitar]

I mean, the example is what you posted. Because I do not know without fetching the resource if it is JSON or not, I cannot know if it should be fetched and embedded or not. Just from the link.

[toomim]

I mean, the example is what you posted. Because I do not know without fetching the resource if it is JSON or not, I cannot know if it should be fetched and embedded or not. Just from the link.

Oh, thank you. That is an interesting example.

[mitar]

So you decide what to do here. We can close it and mark it out of scope, or we could make it an action item to standardize some common cases here.

[toomim]

Ok, I'm marking this out-of-scope. We don't have a lot of time to polish what we've got, and we can always add more stuff later.