JSON base URL for resolving 'text' URL 'fragment' is base URL of HTML document specified as "alternate"?

[danielweck]

I think that 'text' URLs should be just like 'audio' ones, i.e. not restricted to "fragment" which would normally resolve against the base URL of the JSON resource, here being forced to corrspond to that of the HTML document associated with the media overlay (i.e. as specified by the "alternate" property of a web publication's link object, or somehow inferred from the host HTML document itself in case the JSON resource is referenced from an HTML-embedded meta link)

See original comments in the Readium project:

readium/architecture#109 (comment)

[qnga]

Are you aware of the open issue #26?

[danielweck]

Thank you for reminding me of this other issue, @qnga

However here in this issue I would like to place the discussion focus primarily on the fact that the JSON document should (IMO) have a well-defined base URL (usually implied by the URL from which its was fetched, as there is no equivalent of HTML <base> overriding mechanism). Consequently, any link/href/URL relative references inside the JSON would be resolved against the base URL.

[marisademeglio]

I think that solution (2) proposed by me in #26 would help resolve this, no?

[danielweck]

Some cross-posting from the Readium repository:

1. The original text fragment syntax came from this draft, contributed by @danielweck :
   https://github.com/w3c/sync-media-pub/blob/267ef4b44ddb49789196755a08f71ba87ed88751/web-proposal.md#the-sync-media-json-format

Thanks for unearthing this Marisa, it's helpful (I stand corrected, I indeed wrote this proposal at the time). Note: this Markdown document's new location is https://github.com/w3c/sync-media-pub/blob/master/drafts/web-proposal.md

So, the thought process behind this particular spec. "tweak" in my initial draft was to explore the processing model specifically for when a JSON resource is directly referenced (via linking, or embedding) from an HTML document (i.e. without the WebPubManifest level of indirection), in which case the location of the JSON document itself does not necessarily have to be used as its "base" URL/URI/IRI, as this could instead be inferred from the embedding context.

Around the same time, there were discussions in the Web Publications group about "base" in JSON / JSON-LD, notably regarding the impact of "opaque" origin and null base:
w3c/pub-manifest#12
w3c/json-ld-syntax#103
w3c/json-ld-syntax#23 (comment)
See how in JSON-LD, the context @base can be used:
https://json-ld.org/spec/latest/json-ld/#base-iri

...so, to wrap-up, I personally feel very uneasy about my initial draft (use short URL fragment syntax, and assume "base" URL is the associated HTML document), but I also feel uncomfortable about creating an ad-hoc JSON syntax that allows overriding the "base" of the JSON resource for specific properties (i.e. text, ...and maybe even audio). I can of course totally see the benefits from an authoring perspective (i.e. less repetition), so I am keeping an open mind.

I wonder about prior art? Web App Manifest immediately comes to mind, for example see the scope and start_url properties:
https://www.w3.org/TR/appmanifest/#scope-member
https://www.w3.org/TR/appmanifest/#start_url-member
("using manifest URL as the base URL")

[marisademeglio]

The new draft does not have this issue