Experimenting with the Web App Manifest

[HadrienGardeur]

Since things are going to be a little slower during the holiday period, I've started experimenting with porting the WP infoset to the Web App Manifest syntax: https://github.com/readium/readium-2/blob/master/misc/W3C/examples/manifest.webmanifest

This is the first step of a series of documents/examples, where I'll attempt to compare the Readium Web Publication Manifest with the current drafts for WP and Web App Manifest.

The current example adds the following elements to the Web App Manifest:

• author for the creator but we probably need more than that for contributors (this is what we have in Readium)
• published and modified for publication date and last modfication date
• reading_order for the default reading order
• resources for the resource list

I'm also re-using existing elements to cover our requirements:

• name and short_name for the title
• start_url for the address
• lang for the language
• categories for subjects (not currently in our infoset)

I still have mixed feelings about the (lack of) model used in the Web App Manifest, but I'll write a separate document about that.

[HadrienGardeur]

I've updated the example listed above to cover two additional requirements.

1. Identification of the manifest as a Web Publication Manifest

The current WP draft relies on a dedicated rel value to identify a Web Publication Manifest:
<link href="https://example.com/webpub/manifest" rel="publication"/>

This is IMO misguided in the context of a serialization based on the Web App Manifest:

• a Web Publication Manifest becomes a valid Web Application Manifest as well, and the author might want browsers to provide installation for a given WP
• if the link uses a different rel value, it won't be recognized as a Web App Manifest
• the semantics for rel="manifest" are a perfect fit for the WP Manifest
• including two links (manifest + publication) could also be an option, but duplicating info is never a good idea
• minting new rel values for a single media type is not a good idea (there are already other rel values in the IANA rel registry that could work for us, for example collection)

As an alternative to rolling out our own rel value, I added a simple publication flag in the example:
"publication": true

Linking to a Web Publication Manifest would work exactly like the Web Application Manifest:
<link href="https://example.com/webpub/manifest" rel="manifest"/>

In addition to the new flag in the manifest, we could also request a profile parameter for the Web App Manifest:
<link href="https://example.com/webpub/manifest" rel="manifest" type="application/manifest+json;profile=publication" />

2. External Metadata Record

The Web App Manifest syntax lacks an element that we could use to link to an external metadata record.

There are multiple ways this could handled, but my personal preference goes towards introducing a generic linking mechanism, that we'll also be able to use for other things as well (search, annotation, linking back to an EPUB or a PDF).

Instead of rolling our own rel like in EPUB (record), I took a look at the IANA link registry and describedby seem like the best fit.

This is what it looks like in the example:

"links":  [
  {
    "href": "metadata.json",
    "type": "application/json+ld",
    "rel": "describedby"
  }
]

There are two other alternatives that I can also think of:

1. rolling our own dedicated element (record)
2. or linking to the metadata record from our list of resources (secondary resources or whatever we call them)

I'm not a fan of the first option, because we'll end up introducing similar elements whenever we need to link to something else.

The second option sounds a little bit better, but it also indicates to the user agent that the metadata record is part of the publication.

While this is OK for metadata, I don't think it'll work as well for other things that we'd like to link to and I'd rather have a generic element for linking. Here's a more complex example of what we can do with a link element:

"links":  [
  {
    "href": "metadata.json",
    "type": "application/json+ld",
    "rel": "describedby"
  },
  {
    "href": "onix.xml",
    "type": "text/xml",
    "rel": "describedby"
  },
  {
    "href": "/search?q={searchTerms}",
    "type": "text/html",
    "rel": "search",
    "templated": true
  },
  {
    "href": "publication.epub",
    "type": "application/epub+zip",
    "rel": "alternate"
  }
]

---

With these two additions, I think I've covered most of the current WP infoset. I'll go through the WP draft another time and continue improving the example if I find anything else.

[HadrienGardeur]

Found out another missing element from our infoset: the canonical identifier.

1. Canonical Identifier as a Metadata

The first option would be to treat the canonical identifier as an additional metadata element and roll out a new element for it: identifier.

We would simply reference identifier with other elements:

{
  "publication": true,
  "name": "Moby-Dick; or, The Whale",
  "short_name": "Moby-Dick",
  "author": "Herman Melville",
  "identifier": "urn:isbn:9780142437247"
}

2. Canonical Identifier as a Link

If we roll out a generic link element (see previous comment), we could also simply rely on a rel value (canonical or identifier) to provide the canonical identifier for a WP:

"links":  [
  {
    "href": "urn:isbn:9780142437247",
    "rel": "identifier"
  }
]

Since the canonical identifier's usefulness is still TBD, I haven't updated the full example to include one.

[HadrienGardeur]

While working on a comparaison between the current W3C infoset and the Readium Web Publication Manifest, a few additional missing elements came up as well.

I've added both privacy policy and reading direction to the full example.

1. Privacy Policy

Surprisingly, the Web App Manifest doesn't have any element for a privacy policy.

With a generic link element (once again), this could be simply expressed using the privacy-policy rel value, as defined in the IANA link registry.

"links":  [
  {
    "href": "/terms",
    "type": "text/html",
    "rel": "privacy-policy"
  }
]

2. Base Direction

The concept of a base reading direction is completely foreign to Web Apps, which is why it's missing from the Web App Manifest as well.

The current infoset already defines three values for it (ltr, rtl and auto), the most logical option would be to introduce a new element in the Web App Manifest as well (direction).

"direction": "rtl"

3. Accessibility

Based on the current state of the infoset, it's hard to list specific properties for accessibility, but since the Web App Manifest has no dedicated element at all, a WP serialization based on the Web App Manifest would need to introduce new elements as well.

[HadrienGardeur]

So far there are:

• 3 elements that we can re-use for the infoset (name, lang and start_url)
• at least 7 elements missing (creator, publication and last modification dates, default reading order, resource list, generic link element and base direction)
• and probably quite a few more as well (additional roles for creators and accessibility properties)

This feels almost like inventing a new syntax since there are very few elements that we can re-use from the main Web App Manifest specification.

[HadrienGardeur]

In addition to the full example, I also created a minimal viable manifest.

Compared to the minimal infoset:

• there's a title (optional in both WP infoset and Web App Manifest)
• the default reading order is explicitly expressed in the manifest

Here's an alternative with no title and an implicit reading order (discovered through the TOC):

{
  "publication": true,
  "start_url": "https://example.com/Moby-Dick",
  "resource":  [
    {
      "href": "toc.html",
      "type": "text/html",
      "rel": "contents"
    }
  ]
}

I'm not a fan of having an implicit reading order which is why I'd rather use the other example as our reference.

[jce1028]

In regards to Accessibility I think it would suffice to simply indicate the Conformance Level property as a new element :accessibility element of the WP manifest.

The properties could include the standard published under ( WCAG 2.0 or 2.1) and link to the standard referenced and the other properties would be the conformance level (A, AA, AAA).

Wether it is a link element or simply another metadata set in record I have no opinion on. However I believe the pros and cons you have enumerated in other new elements for metadata apply.

[clapierre]

In the EPUB Accessibility 1.0 Discovery and Conformance Specification we have a "conformsTo" property which sounds like what you are talking about here, I think it would be a good idea to make sure we sync these two together

https://www.w3.org/Submission/epub-a11y/#sec-conf-reporting

[HadrienGardeur]

@clapierre Is there any equivalent for conformsTo registered at IANA, ideally in the link relation registry?

IMO there are two different approaches for expressing accessibility, that can be complementary:

• metadata (ideally based on schema.org)
• linking to specific profiles (ideally using a controlled list of profiles URIs + a well-known rel value)

If we don't have a dedicated rel value, maybe profile could do the trick.

[BigBlueHat]

@HadrienGardeur what are the expectations of a user agent greeted with one of these manifests?

[HadrienGardeur]

@BigBlueHat that's a different issue, I mainly explored the technical side of it here.

UX has been recently discussed in #32, see @baldurbjarnason comment at #32 (comment) and my reply at #32 (comment).

Let's focus on UX over at #32 and keep discussing the syntax here.

[BigBlueHat]

Sorry that was unclear. This isn't about user experience, it's about what the user agent greeted with one of these would do with it.

Currently, a user agent will go through the steps defined in Manifest life-cycle. The end result being a launcher icon (using something from icons) showing the name (or short_name). When clicked a slightly customized browser will load the "purely advisory" start_url and then the Web App itself will take it from there.

Any publication using an "extended" Web App Manifest will need to itself be a Web App (i.e. provide it's own reading experience) which then muddies the value of putting this data into the Web App Manifest--unless there's some action the user agent must do with what's expressed therein.

[HadrienGardeur]

This is very much tied to the UX and features implemented by browsers. The Web App Manifest lifecycle exists precisely because it was designed to be installed.

BTW, I agree that "installing" and listing potentially hundreds of publications among a list of Web Apps is not the UX that we're looking for in a browser, but that's a discussion that I'd rather have in #32 once again.

[BigBlueHat]

My point is that a Web App Manifest is not itself used by the Web App. Web Apps exist without them, and are (for the most part) in "ignorance" of them. They're not a required piece of technology for building a Web App, only for signaling an interest in having an icon and stripped-down browser made to run the Web App.

The Web Publication manifest is entirely different as it defines the Web Publication itself and is mandatory for a group of resources to be considered a "Web Publication."

[BigBlueHat]

Also, language direction is defined as dir, but like lang for stating language these are only defined to cover the manifests textual content (name, short_name, and description), and not the language of the Web App itself.

[HadrienGardeur]

Also, language direction is defined as dir, but like lang for stating language these are only defined to cover the manifests textual content (name, short_name, and description), and not the language of the Web App itself.

Which is why I didn't use dir in my examples and comments above.

If we also remove lang from the list of re-usable elements, this means that we only end up with name and start_url that can be reused.

[rdeltour]

Following up on a comment I made in #121, which is better discussed here.

---

@HadrienGardeur said:

we share very little with it (infoset, use cases, syntax, processing are all quite different)

I personally think we share more than "very little" (for lack of a real means to quantify):

• our processing and infoset requirements are more complex than WAM, but not radically different either; extending the WAM is a viable option IMO.
• syntax is out of the equation, as we can still decide to use WAM’s, RWPM’s, HTML (heck, even XML 😬).
• use cases are not a fundamental defining part of WAM, even if a particular use case (app installation) is obviously underlying the design. As I commented several times, this particular use case is btw not very far from some of ours (e.g. installing a publication to a library).

I don't think that's it's truly designed with extensibility in mind (compared to the RWPM)

Mmm. It has the benefit of having explicit extension points, which is at least a sign that extensibility was in mind. If there are indeed shortcomings, the editors can probably be convinced to improve the weak spots.
Is there a specific feature/processing that we need and currently can't be designed as an extension to WAM?

---

@BigBlueHat said:

there may be situations when you don't want a WP to be "installed."

OK, right.

However, anything extending WAM will also trigger an installation request (in supporting browsers...obviously). If that's not what you (ever) want, then don't put content into a WAM and link to it as they describe. Use something else.

I disagree, as it is an implementation decision. If we add a flag (e.g. a "type" field, defaulting to "application" and extensible to "publication"), it should be pretty straightforward to update the implems to switch that installation based on that flag’s value. In fact, that can be seen as a "graceful degradation", which can perfectly make sense.

---

To summarize, my point is that right now I don't think there is a strong enough case to not extend WAM. Maybe there is in effect (as intuited by @HadrienGardeur and @BigBlueHat), but I don’t see it documented with clear and strong arguments.

We have an option to use and extend WAM, which is largely used and implemented (albeit for a somewhat different use case, but not very far from ours), and is (to some extent) considered as a viable path by some people from browser vendors and TAG.
We also have an option to design our own format and spec, possibly at the risk of entrenching ourselves in the publishing silo.
If the latter option is the most technically sound, I'd like to see very strong arguments for it to be chosen.

[HadrienGardeur]

@rdeltour there are no clear benefits from using the WAM either.

Its infoset, lifecycle, syntax and affordances do not cover our requirements. I've never said that we can't extend it (this is what this issue is all about, I covered pretty extensively how it could be done), but is it really worth it?

This wouldn't help us much with browsers either, as they'd have to provide completely different affordances and parse an almost completely different document for WP.

The WAM also has IMO poor extensibility (I'll cover that in a separate comment) and doesn't have a clearly defined abstract model.

I disagree, as it is an implementation decision. If we add a flag (e.g. a "type" field, defaulting to "application" and extensible to "publication"), it should be pretty straightforward to update the implems to switch that installation based on that flag’s value. In fact, that can be seen as a "graceful degradation", which can perfectly make sense.

There's nothing straightforward about asking browsers to completely change their behaviour when they detect a WAM.
There might also be situations where the content provider actually wants both "install as a Web App" and "read as a Web Publication" affordances. With a flag or a type, we would only get one and not the other.

As a content provider:

• there's barely any redundancy at all between a WAM and a WP manifest (name and maybe start_url, but the Start URL could be different)
• with two different manifests, I have control over which affordance I'd like to trigger

[HadrienGardeur]

@rdeltour about extensibility...

The WAM has a pretty basic approach to extensibility:

• do whatever you want
• prefix it if it's proprietary
• register the extension
• no default way of processing these extensions

This is very different from RWPM where the approach is:

• provide more limited but clearly identified extension points
• don't reinvent the wheel, use existing vocabularies and registries as much as possible (schema.org, link rel, media types)
• a default option for processing all extensions

Metadata

In the WAM, none of the metadata are tied to an existing vocabulary and there's no mapping to existing vocabularies either.

In the RWPM, the majority of the metadata are based on schema.org and the manifest benefits from being based on JSON-LD and schema.org in terms of extensibility:

• all schema.org properties are available in the default context through the schema: prefix (this means that for example, all accessibility properties from schema.org are available)
• since this is JSON-LD, you can also use full URIs as well if you want
• groups that have domain specific metadata can also work together and define a context document that would be added to the registry

Links

WAM doesn't have a concept of links, the closest thing that it has is the ImageResource dictionary. This element is:

1. mostly specialized for images
2. doesn't provide any extension point aside from type (media type)

In RWPM, there's a much more generic concept of Link Object that has many extension points:

• one or more rel, that you can extend using the IANA link registry or full URIs for proprietary extensions
• type for media types
• support for both URI and URI templates (there's a templated flag) which opens the door to service discovery (search, annotation, dictionaries...)
• properties for EPUB-style properties

[js-choi]

Have there been plans to engage with the WPWG regarding improving WAM’s extensibility for these use cases?

[rdeltour]

About the benefits of reusing WAM, answering to @HadrienGardeur’s comment

there are no clear benefits from using the WAM either.

I believe there are, on the contrary:

• we don’t have to redefine WAM’s lifecycle, only provide the specify the processing logic for WPM extensions.
• WAM as implemented today by major browsers, can and is used by de-facto Web publications. In other words, it can already be used (along with some other techs) to implement some of the envisioned affordances.
• WAM with WPM extensions could –under some circumstances– gracefully degrade to WAM as implemented today.
• there’s a lot of momentum around WAM and PWA, and this could help in getting Web devs’ and browser vendors’ interest.
• I think many of the current WAM members can actually apply to Web Publications (more on that later in the comment).

This wouldn't help us much with browsers either, as they'd have to provide completely different affordances and parse an almost completely different document for WP.

I disagree. A good chunk of the parsing and processing logic would be the same. The default affordance provided by browsers today works well for at least one use case. That we envision additional affordance doesn’t change that. Some of these additional affordances can probably even piggy-back on the current affordances’ implementations (e.g. code to show a banner asking "Add to my books library" would most probably share a lot with the code to show a banner "Add to home screen").

There's nothing straightforward about asking browsers to completely change their behaviour when they detect a WAM.

Of course, and the publishing industry can’t ask that. But I think it’s easier for a browser vendor interested in Web Pub to gradually add to an existing implementation, than work on something from scratch.

There might also be situations where the content provider actually wants both "install as a Web App" and "read as a Web Publication" affordances. With a flag or a type, we would only get one and not the other.

You know it’s not true. The implementation can let the user decide, like current PWAs let the user decide if they want to install as an app or stay in the browser.

As a content provider:

• there's barely any redundancy at all between a WAM and a WP manifest (name and maybe start_url, but the Start URL could be different)

I disagree. To be honest I don’t even understand why you keep making this statement.

For instance:

WebAppManifest dictionary

• dir member: can be used as-is
• lang member: can be used as-is
• name member: can be used as-is
• short_name member: can be used as-is
• description member: can be used with a slight editorial tweak to the definition.
• scope member: can be used, the concept makes sense in Web Pubs.
• icons member: can be used, for instance to provide the publication’s cover thumbnail.
• display member: can be used, and extended to cover our affordances
• orientation member: can be used as-is
• start_url member: can probably be used as-is to define the publication’s entry point
• serviceworker member: can be used as-is by some publications, or ignored
• theme_color member: can be used as is, or ignored
• related_applications member: could potentially be used to define related publications.
• prefer_related_applications member: not sure it makes sense, but if yes see above.
• background_color member: can be used as-is
• categories member: can be used as-is
• screenshots member: can be used as-is
• iarc_rating_id member: not sure if this cover publications

Of course, we’d certainly need to provide an extension member for more detailed metadata. But this doesn’t make the current WAM members any less usable.

• with two different manifests, I have control over which affordance I'd like to trigger

As said above, the choice of the affordance is mostly the user’s, and using WAM only doesn’t hinder that.

[rdeltour]

About the WAM extensibility, answering to @HadrienGardeur’s comment

The WAM has a pretty basic approach to extensibility

… which hasn’t be proven to be too limited. If it is, we could identify the weak spots and can probably work with the WAM editors.

no default way of processing these extensions

so what, as long as the extensions define their processing logic?

This is very different from RWPM

Agreed, but it’s not the topic of this issue :-)

In the WAM, none of the metadata are tied to an existing vocabulary and there's no mapping to existing vocabularies either.

Right.
I’m not a JSON-LD expert, but couldn’t we transparently define a context to precisely tie this metadata to an existing vocabulary? (cc @iherman)

Also, we’re free to define metadata in WP extensions as we like (possibly following RWPM’s approach), which makes this point rather moot.

WAM doesn't have a concept of links

Likewise, it’s not an issue. If we need this concept in our extension, we can define it there.

[rdeltour]

Have there been plans to engage with the WPWG regarding improving WAM’s extensibility for these use cases?

We met with some WAM editors at TPAC last November, although we didn’t specifically raise any extensibility issue. I’m not sure these latter are well enough defined and described to be brought to WPWG yet.

[baldurbjarnason]

I know I've asked a variation of this question elsewhere, but doesn't this issue as well boil down to a single question?:

What do browser vendors want?

1. Are they more likely to implement publications as a web application manifest superset? (I.e. 'publication' becomes the fifth display mode that triggers publication-style UI affordances to a PWA.) If so then that automatically becomes the logical path for us to take even if the WAM doesn't otherwise work that well for publications in a technical sense. And then we can just go all in on reusing WAM features like the 'display-mode' media query. Which could be nice.

2. Or do they think that would clutter the dashboard/home screen and are more likely to implement publications that are defined more like documents? I.e. a cluster of resources with shared metadata and links that would be more suitable to the 'reader' modes they've implemented. Which could be nice as well, just in a different way.

3. Or do some of them have other ideas we haven't thought of?

The answers to these questions could make individual issues we have with the technical details of the web app manifest irrelevant (i.e. extensibility, linking, etc.). Even if that interest comes only from one vendor that'd be enough to give us direction.

It seems to me that there is a big risk that browser vendor intent makes whatever technical argument we're having irrelevant. The benefit of implementation trumps pretty much any other technical benefit you can think of.

It'd be a little bit reassuring if somebody at least confirmed that they don't care either way, are willing to trust this working group's judgement, or can't agree on this either.

If we can't get direct feedback then maybe one of the WG chairs can file an issue with the question? It basically boils down to whether there's interest among browser vendors in implementing "display": "publication" or not—the rest is mechanics. If not, since extending the WAM doesn't really make sense if it doesn't come with a display mode then it's probably best to keep the WAM and publication manifest separate to make polyfilling easier.

(Pretty sure a question like that would be taken more seriously if it came from one of the chairs.)

To put it another way: shouldn't this discussion happen first in a github issue in the manifest repository?

I could well be way off base and missing something here and there are very good reasons not to do this. If that's the case, apologies.

[rdeltour]

Great point @baldurbjarnason, I fully agree that the opinion of browser vendors is critical here.
I think this fundamental architectural issue could also be worth being asked to the TAG.

Just a quibble on your second point:

Or do they think that would clutter the dashboard/home screen

as said elsewhere this is a red herring IMO, as a WAM-based publication could very well be sent to another place (a "publication library") to avoid this issue.

[HadrienGardeur]

I mostly agree with you @baldurbjarnason but so far we haven't heard a single thing from browsers.

All the points that @rdeltour has listed apply if and only if browsers are commited to implementing them, otherwise we're just polluting the WAM by extending it.

Also, you're completely forgetting something: browsers only offer the app install affordance under very specific conditions.
In Chrome for instance:

• you need to visit the Web App multiple times (that's not what we want for WP)
• you need a Service Worker (this is a very different approach to caching, since we list resources instead of providing a script to do that)
• you need to include icons in several resolutions (not something that makes sense for publications, and icons have a very different ratio than book covers for example)
• you need to serve all resources using HTTPS

On the other hand, we already have multiple organizations implementing RWPM and some of them using it in production already. I've seen some examples that could be used as polyfills or could be a good starting point for browser extensions as well.

To go back to some of @rdeltour points...

I think many of the current WAM members can actually apply to Web Publications (more on that later in the comment).

I've never said anything about WAM members not being useful. What I've pointed out (and clearly documented) is that the WAM members are not sufficient for our WP infoset since they only cover a very very limited sub-set of what we need.

You say that you disagree that there's very little redundancy, but you're not proving your point at all, you're just listing WAM members.

Only the following members MAY be redundant between the two:

• name for the title
• start_url for the WP address (but the address of the WP and its Web App can be two completely different things)
• lang for the language of the manifest members (but I've opened an issue about that at Expressing metadata in multiple scripts/languages #124 )
• dir for the reading members of the manifest members (but Expressing metadata in multiple scripts/languages #124 applies to it as well)

At worse, out of 18 members that you've listed, 4 of them might be redundant (and it's likely to be 2 IMO, since I believe that our current infoset for language and reading direction is not a good idea).

Also, we’re free to define metadata in WP extensions as we like (possibly following RWPM’s approach), which makes this point rather moot.
Likewise, it’s not an issue. If we need this concept in our extension, we can define it there.

Oh sure, we're allowed to reinvent everything. But that's exactly the main issue with the WAM, it doesn't cover at all what we need, so we need to create new members for pretty much everything.

[baldurbjarnason]

Also, you're completely forgetting something: browsers only offer the app install affordance under very specific conditions.

This is something that is clearly still in flux. Apple's upcoming implementation seems to be mostly backwards compatible with earlier home screen apps so clearly has different requirements. Firefox on Android has also changed their original Android implementation so that now if you browse to a PWA an icon to add install it appears in the toolbar. The possibility that publication web apps might get a different treatment/different processing doesn't seem to be out of the question given that the requirements vary across browsers already.

And HTTPS is almost certainly going to have to be a requirement for browser implementation anyway. It's a hard requirement for Firefox for all new features and a strong preference for the rest. So I think it would be unrealistic of us to expect browsers to support anything we come up with in this WG in a non-secure context.

In any case, this doesn't answer my question: shouldn't somebody, on behalf of this working group, go to the manifest repository and file an issue asking these questions?

[HadrienGardeur]

Some of the things that browsers would have to agree to support:

• provide a publication display mode for Web Apps (that would follow what I've documented in "Displaying Web Publications")
• add support for new affordances that are specific to WPs ("open in reader mode")
• trigger the WP specific affordances under conditions that are completely different from the ones they're using with Web Apps
• extend their WAM processing to cover our own processing rules

Anything else missing?

[rdeltour]

All the points that @rdeltour has listed apply if and only if browsers are commited to implementing them, otherwise we're just polluting the WAM by extending it.

There we absolutely agree Hadrien :-)

I assumed the premise was that we were looking for browsers to ultimately implement Web publications. Otherwise, we're really back to the EPUB way of using Web techs for something that’s not really the Web.

I've never said anything about WAM members not being useful.

You said:

there's barely any redundancy at all between a WAM and a WP manifest (name and maybe start_url, but the Start URL could be different)

which draws an inaccurate picture IMO, and with which I strongly disagree.

You say that you disagree that there's very little redundancy, but you're not proving your point at all, you're just listing WAM members.

I not only listed WAM members, but also said which made sense in the context of Web publications (almost all of them).
The implication (which I thought was obvious, but I should have perhaps stated more explicitly) is that they can all be part of the WP "infoset", so WAM and WPM overlap more than about just name and start_url.

[HadrienGardeur]

The implication (which I thought was obvious, but I should have perhaps stated more explicitly) is that they can all be part of the WP "infoset", so WAM and WPM overlap more than about just name and start_url.

@rdeltour they COULD be part of the WP infoset, but currently they're not. Of course there would be more redundancy if you align the WAM infoset with the WP infoset but that's not currently the case.

[js-choi]

In any case, this doesn't answer my question: shouldn't somebody, on behalf of this working group, go to the manifest repository and file an issue asking these questions?

@baldurbjarnason: I’m an outsider to the WG, but I had actually already been considering, for the past several weeks, raising an issue in the WAM repository to ask its authors for their perspective on this issue. I did not want to step on any toes of anyone in the WG who had their own plans, though.

[iherman]

@baldurbjarnason, as an info: the chairs have reached out (yesterday...) through direct emails to some people in the browser communities (and members of the TAG, which may also have precious input). Ie, to some people we have identified in the Edge, Safari, Chrome, etc, teams. That mail explicitly referred to this WAM/WPM issue (alongside the packaging one). Hopefully that will trigger some feedbacks we indeed need.

Raising an issue in the WAM repository, as you propose, is also a direction to go, and I agree that, in case we are not successful in getting the necessary input, we should also do that. (Or maybe in parallel.)

Cc @TzviyaSiegman @GarthConboy

[mattgarrish]

@rdeltour Is your idea that the manifest is just a hand-off of information to a user agent: it solely provides information that allows the publication to be stored in a library/bookshelf, but what "reader mode" or iframed reading experience that user agent uses to present the publication, and when or how it is initiated relative to the regular browsing context, is out of scope? (So we only define certain expectations for how the members of the manifest can be used?)

Or can a web publication trigger a specialized reading mode without it also being added to a library/bookshelf, in which case what becomes of "installation" relative to WAM?

[rdeltour]

@rdeltour Is your idea that the manifest is just a hand-off of information to a user agent: it solely provides information that allows the publication to be stored in a library/bookshelf, but what "reader mode" or iframed reading experience that user agent uses to present the publication, and when or how it is initiated relative to the regular browsing context, is out of scope? (So we only define certain expectations for how the members of the manifest can be used?)

I think so (if I understand correctly your question).
Basically, similar to how WAM participates in enabling an "app" experience from Web content, the publication-extended WAM would participate in enabling a "publication" experience from Web content.

Or can a web publication trigger a specialized reading mode without it also being added to a library/bookshelf, in which case what becomes of "installation" relative to WAM?

Like for the current WAM, the user can opt-out of the installation process.
In addition, we could envision writing a section like "Reading-mode", in a manner similar to WAM’s "Installable web applications", to specify the process of opening a publication in reading mode.

[mattgarrish]

Like for the current WAM, the user can opt-out of the installation process.

Right, but if they opt out then the user agent itself has no involvement in what happens next. This is what I'm trying to understand in relation to an extension of WAM. If we follow the WAM model, shouldn't that also be true of web publications? (i.e., only if you choose to "install" should the reading mode be initiated as a subsequent step after loading the publication)

It seems like "installing into a library" would be the primary focus of the specification.

We have two overlapping ideas in play at times: one that the web publication is maintained for the user (the library) and the other that a web publication simply triggers a special kind of reading experience as you're browsing the web. I know this is where we really need browser input to determine whether one or both are feasible, but I wasn't sure if you were thinking of ruling out the latter case to be more aligned with web app manifest.

[mattgarrish]

ruling out the latter case to be more aligned with web app manifest

And as my brain isn't fully awake yet, I don't mean that it isn't important to consider the reading experience, only that the "browsing state" or context that the user agent specifically creates to facilitate this shouldn't be our focus.

[mattgarrish]

Sorry, accidental mouse click going to close the tab...

[HadrienGardeur]

This can be closed since we've adopted JSON-LD + schema.org in our draft.