Closed iherman closed 4 years ago
Hi Ivan,
One question -- is there any reason manifest
(already registered) can't be used?
Hi @mnot,
A web application manifest (target of manifest
) and the publication manifest (target of publication
) are very different functionally and even syntactically. The syntax of the latter abides by JSON-LD, relating it to schema.org, which is absolutely not the case for the former; the 'target' processor is different (an audiobook reader app, which is a genuine processor for a publication manifest is not a Web Application), etc. We believe that using the same rel
value would, therefore, be misleading and technically wrong.
It is unfortunate to have a similar name, and the WG had its round of discussion on this, but we never found a really suitable alternative term. The final decision has therefore been to keep to this terminology.
I understand that they're different syntactically, but that can be indicated by the type
attribute of the link. Remember that link relations aren't supposed to specify a particular syntax, since that's the function of a media type.
What I'm curious about is how are they different functionally / semantically; it's not clear from reading the description.
A Web Application manifest is processed by a browser, installing an "Installable Web Application". The semantics of the manifest itself (i.e., the specified terms and their meaning) is about that usage, obviously, like icons, colors, or the description of the application. The processing of a web app manifest (to be executed by a browser) is described in a dedicated section of the spec, which also affects the browsing context used by the Web App. The spec also defines an associated browser API.
The publication manifest has two targeted processors. On the one hand, it is a vocabulary based on schema.org (to be precise, and extension thereof), meaning that it is defined so that its content can be interpreted by search engines using the schema.org vocabulary accessing general metadata for a publication. On the other hand, it is also to be processed by "reading systems", which may (but not must) be an "Installable Web Application", may be an integral part of a browser, or can be a completely separate application like Google Play or Kobo. (Actually, at this moment, the implementation base we know of essentially consists of separate, dedicated applications). It defines its own, separate processing in a dedicated section of the spec which defines a "canonical" data representation of the metadata, whose exact usage by the reading system is left to the discretion of the latter. Consequently, there is no specification for an API.
I consider these two as complementary.
I hope this helps...
I'd only add that the publication manifest is more akin to the EPUB package document than an installable web application, if that helps differentiate the uses.
While the existing definition of manifest is sufficiently vague, the practical implementation of the term for web apps makes it unsuitable for publications, as Ivan has noted.
I wonder if we can perhaps avoid any sense of duplication by taking "manifest" out of the description, though. Would wording it like the following take out some of the potential confusion:
"Links to structured information about a publication, such as informative metadata, a list of resources, and a default reading order."
makes it unsuitable for publications
And just to clarify, this is meant only in the general case. As noted above, you could make a publication that is installable, but that's not a primary case of the specification. Keeping the relations separate allows both cases to exist independently.
Registration requested. Thanks for the details.
@mnot thanks. Just process questions: is there anything we have to do now, or are all subsequent steps automatic and we will just be notified?
It's already in the registry.
Enter the details of the link relation type below:
Any additional information (this will not be included in the registry)?
Cc: @mattgarrish @TzviyaSiegman @wareid @GarthConboy