clarify packaging (incorporation) rules

[marisademeglio]

We discuss two modes of packaging: standalone and in web publications.

I would assume that there is no reason to combine modes - you use one or the other - but we should say so explicitly.

[iherman]

Bikeshedding on terms: we use the term 'packaging' for Web Publications, see, e.g., LPF. Can we find a different term for this in this context?

[marisademeglio]

Sure, lots of terms would work here. "Including"? "Referencing"? "Incorporating"? "Using with"? Are any of these problematic?

[iherman]

"Incorporating" is probably the closest. At it is an easy replacement in the title of https://w3c.github.io/sync-media-pub/packaging.html#with-webpub, for example.

Thx!

[marisademeglio]

"Incorporating" it is. Coming soon..

My reason for opening this issue though was to discuss that there are two ways to incorporate sync narration:

1. in the head of an HTML document
2. in a publication manifest

If you are doing (2), should you also or never do (1) ? It seems redundant but not harmful. @danielweck what do you think?

[danielweck]

I think the idea was to make it possible for "plain" HTML documents (i.e. not part of a "web publication" aggregating context) to reference their associated sync-media JSON, in which case a sync-media processing agent could be a Javascript running inside such HTML documents, designed to provide the synchronized playback experience at the level of individual documents (i.e. no notion of inter-document linear reading order / progress along a "spine" of documents).

If an HTML document contains a link to its "web publication" context, then a sync-media processing agent can use the JSON manifest as a level of indirection to obtain a link to the sync-media JSON associated with that HTML document. Alternatively, this link could be declared directly inside the HTML head, thereby saving the unnecessary indirection hoops.

If however, an HTML document does not contain an explicit back-reference to its embedding "web publication" context (either because it does not have one, or because there is an assumption that the "web publication" processor maintains such context in some implicit fashion), then the only way for a sync-media processing agent to discover the link to the sync-media JSON is to obtain it from the HTML head. Alternatively, the sync-media processing agent could work hand-in-hand with the "web publication" processor, and therefore would have access to the host publication context for that HTML document.

[marisademeglio]

1. "plain" HTML document has this in the head: <link rel="sync-media" href="sync-media/index.json" type="application/vnd.wp-sync-media+json"/>

and that takes care of the association.

2. Web pub HTML document has this in the head: <link href="https://example.com/webpub/manifest" rel="publication"/>

And then the manifest has sync media referenced from the reading order:

{
    "url": "chapter1.html",
    "alternate": 
    {
        "url": "chapter1.json",
        "encodingFormat": "application/vnd.wp-sync-media+json"
        "length": 1669
    }
}

3. Audiobook manifest has an association in the manifest:

   {
   "url":            "chapter1.mp3",
   "encodingFormat": "audio/mpeg",
   "name":           "Chapter 1 - Loomings",
   "alternate": 
   {
       "url": "chapter1.json",
       "encodingFormat": "application/vnd.wp-sync-media+json"
       "length": 1669
   }
   }

The processing agent doesn't discover the HTML document until it opens the sync media file and sees the text element references (aside: we should make sure these can refer to a file, not just the element IDs).

I don't see much advantage to requiring an association in the HTML head for cases (2) and (3). Slight player convenience? Should we leave it optional? Or require it for consistency?

[llemeurfr]

For cases 2 & 3, I vote for avoiding any duplication of the association in the HTML head; it would be error prone and of no use for users agents manipulating manifests.

Note: we may well never see HTML pages with a link back to their publication manifest. Even if this could enhance the discoverability of the publication, most publications processes may well be "mono-directional", i.e. a) create the HTML content b) create a manifest which glues the resource togetherc) create a PEP with a ToC. And don't edit back the content.

[marisademeglio]

At the moment, we have two draft documents:

1. synchronized narration itself
2. how to incorporate into a publication manifest

It does not seem to me that we need to make an official statement on how to integrate with standalone HTML (i.e. not in a publication) at this time.