Clarify the manifest retrieval from the package?

[w3c]

Clarify the manifest retrieval from the package?

[bjdmeest]

I would assume retrieving the manifest from a package is part of the
package specification, and not in scope of this note, and all those
mentioned scenarios could be defined differently for every packaging
solution.

The 'main' HTML part is in IMHO just a proposal (as is the entire note,
actually), use cases/experience/.. should make clear whether that
alternative is viable or not.
The same goes for HTTP Link headers, etc, but we have to start somewhere.

2016-03-16 10:37 GMT+01:00 Romain Deltour [email protected]:

Currently we're pretty evasive about how the manifest is retrieved from a
packaged PWP. The algorithm says:

If the response is a packaged PWP instance (...) unpack the package, and
retrieve the manifest embedded in the package

Under the hood, several scenarios can be envisioned:

• there is a standalone manifest at a known location (as is the case,
  to some extent, in EPUB)
• the manifest is combined from several manifests ; for instance, a
  "main" HTML document in the package may contain an embedded manifest and/or
  link to manifest(s).

The "packaged" step in the algorithm may well have to go back to the
"resource as HTML file" step, at some point after the unpackaging.

It seems odd that we clearly define the manifest retrieval and priorities
for the "single HTML file" but we do not for the "packaged" stage.
On the other hand, I can hardly see how we could do that given that we
leave the packaging solution entirely open...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#22

[iherman]

On 16 Mar 2016, at 10:37, Romain Deltour [email protected] wrote:

Currently we're pretty evasive about how the manifest is retrieved from a packaged PWP. The algorithm says:

If the response is a packaged PWP instance (...) unpack the package, and retrieve the manifest embedded in the package

Under the hood, several scenarios can be envisioned:

there is a standalone manifest at a known location (as is the case, to some extent, in EPUB)
the manifest is combined from several manifests ; for instance, a "main" HTML document in the package may contain an embedded manifest and/or link to manifest(s).
The "packaged" step in the algorithm may well have to go back to the "resource as HTML file" step, at some point after the unpackaging.

It seems odd that we clearly define the manifest retrieval and priorities for the "single HTML file" but we do not for the "packaged" stage.
On the other hand, I can hardly see how we could do that given that we leave the packaging solution entirely open...

Exactly. We do not even know what packaging we would use. In other words, we have no choice than to leave this open for now.

You are right that we may have a situation whereby the manifest retrieval from within a package would follow the same principles. Actually, that is what I would prefer, personally, and that would mean the same algorithm could be used. That is all fine….

[iherman]

I have added a separate note after the algorithm referring the issue that handling a package is, in this respect, a black box. See PR #25.

[bjdmeest]

Closed as per discussion on today's call