... or we fall back on requiring the https://www.w3.org/TR/pub-manifest, or setting this one as a default.

https://www.w3.org/TR/pub-manifest, or setting this one as a default

That would give it a value, but what does it mean for processing? There are no behaviours associated with a generic pub manifest.

It could mean something like no specific behaviour is defined for that manifest (apart from the processing steps defined in the spec), and the URL just says that the manifest is meant to be a valid manifest per the pub-manifest specification.

Obviously not very useful. But it makes testing, etc, more straightforward; it may also allow unforeseen or experimental readers to develop with some local knowledge without the need to change the manifest.

(To be clear: I did not think it through 100%, so there may be fatal caveats.)

It could mean something like no specific behaviour is defined for that manifest

In theory, yes, but what does a dedicated audiobook player presented with this manifest do, for example? Won't it have to try and open the publication as an audiobook if it doesn't barf on it?

If it was just the web we were talking about it probably wouldn't matter, you could process the manifest and just leave whatever linked to the manifest alone as a web page. But for distributed content there's going to be some expectation of what the package contains. I don't think we can ever capture what that expectation is, though.

It seems like the user agent could opt to either: 1) issue a fatal error and not render the content; or 2) issue a validation error and continue processing based on whatever it is capable of rendering.

In theory, yes, but what does a dedicated audiobook player presented with this manifest do, for example? Won't it have to try and open the publication as an audiobook if it doesn't barf on it?

To be honest, I do not really know but, clearly, if somebody creates an audiobook, than he/she should definitely set the right pointer.

Again, I would regard such a pointer (ie, to the pub-manifest) more as some sort of a testing/development conformance profile, without specifying it further. Which, I guess, means that my option would be:

2. issue a validation error and continue processing based on whatever it is capable of rendering.

Maybe even adding the pub-manifest reference as a default setting in the processing step.

Maybe even adding the pub-manifest reference as a default setting in the processing step.

Ya, I was thinking about this when I got up and if we default to https://www.w3.org/TR/pub-manifest, maybe we could recommend in the audiobook specification that user agents attempt to open such publications.

Of course, every profile would have to say the same, but at some point there's no way to get consistent behaviour for an unidentified profile.

maybe we could recommend in the audiobook specification that user agents attempt to open such publications.

I am not sure what you mean. Some user agent can be prepared for a general profile, some may be extremely specialized and would understand only a specific profile(s).

Some user agent can be prepared for a general profile, some may be extremely specialized and would understand only a specific profile(s).

Yes, and when a specialized audiobook UA processing a publication comes across this undefined "profile" because someone left out conformsTo, what does it do with the publication? Shouldn't it still attempt to open it, or where does the failure occur? It's not about whether some deliberately puts the profile in, although the idea that there can be a "general profile" is confusing to me.

How a user agent can prepare for an undefined implementation, for example? We don't actually define any presentation logic in the manifest itself, so what governs its rendering?

If we're expecting a common interface, then we need to go beyond the manifest so that there is meaningful presentation logic associated with pub-manifest that all implementations can inherit. But that seems like the path back to web publications.

Otherwise, a profile doesn't have to make any modifications to the base profile, but it should at least distinguish itself as a profile in order to differentiate itself as it will have to add some rules governing its content and consumption.

I tried to gather my thoughts on all this. I think we cannot avoid that the characteristics of the User Agent are somehow part of the processing steps, but I do not think this is bad (and it is already the case).

Obviously, the terminology and the editorial style should be made better, and I did not look at how the bullet points should be distributed over the document.

In the Manifest

• The value of the conformsTo property is a single conformance identifier, or an array thereof. These conformance identifiers are absolute URLs.
• Each conformance identifier SHOULD be dereferencable to a document that describes the meaning/interpretation of this identifier.
• Each publication profile MUST define a conformance identifier, also referred to as a publication conformance identifier. A publication profile specification SHOULD describe a minimal behavior that a User Agent should provide if it understands that profile.
  • specifications (including specifications that do not define a publication profile) MAY also define conformance identifiers that are not publication conformance identifiers, e.g., for the purposes of accessibility. This specification does not apply or define any rules on how those extra identifiers are used.
• Each user agent SHOULD announce the publication conformance identifiers it understands, i.e., whose behavior, described in the corresponding document, it can provide as a minimal behavior.
• This specification defines a specific publication conformance identifier, namely https://www.w3.org/TR/pub-manifest/. This is primarily used for testing purposes, but very simple user agents (e.g., simple browser extension) may also be able to refer that profile providing a basic, reading experience for the publication (e.g., "just" displaying the resources in the reading order). There is no minimal user agent behavior assigned to this publication conformance identifier.

In the processing steps

(This should replace of step §4 in the PR version)

Let profile be that the User Agent understands and the manifest conforms to. Set profile as follows:

• If manifest["conformsTo"] is not set, this is a fatal error, return failure
• If manifest["conformsTo"] is a single value, check whether the User Agent understands that value. If yes, set profile to that value, otherwise this is a fatal error, return failure
• If manifest["conformsTo"] is an array, consider the values on the array, moving from the first item to the last:
  • if the User Agent understands that value, set profile to that value, then break
• If profile is not set, this is a fatal error, return failure

Notes:

• I deliberately avoided to overuse the term 'profile', and used the terminology on conformance identification. Otherwise we get to the terminological issue that the pub manifest document does not define a profile, "just" a vocabulary...

• This is a draconian behavior, akin to XML processing, which is not very 'Webby'. On the other hand, we do not have any minimal User Agent behavior defined, so it is difficult to define/imagine anything else.

• We could say that the https://www.w3.org/TR/pub-manifest/ identifier is some sort of a default; this means that the first step should say something like:

  • If manifest["conformsTo"] is not set, and the User Agent understands the publication conformance identifier with the value of https://www.w3.org/TR/pub-manifest/, then set this as the value of profile. Otherwise this is a fatal error, return failure.

  I must admit that, at this point, I am undecided whether such default value for conformsTo is a good thing or not.

This issue was discussed in a meeting.

• No actions or resolutions

This issue was discussed in a meeting.

• No actions or resolutions

B.t.w., looking at the processing step and the WebIDL part: in fact, the WebIDL should contain a profile value (and not an array) and not a conformsTo value. The WebIDL represents the internal data structure (not the manifest JSON file), and the processing actually picks a single profile value here...

Looking at the document version October 14... To avoid misunderstanding, here is what the algorithm says:

(§ 2.7 Profile Conformance) Let profile be the profile the manifest conforms to. Set profile as follows:

a. If manifest["conformsTo"] is not set, validation error, set to « "https://www.w3.org/TR/pub-manifest" ».
b. If manifest["conformsTo"] does not include a URL of a profile the user agent is capable of processing and/or rendering, fatal error, return failure.
c. If manifest["conformsTo"] includes the URLs of more than one profile the user agent is capable of processing and/or rendering, set to the first in the array in the case of conflicting requirements.
d. Otherwise, set to the profile defined by the URL the user agent is capable of processing and/or rendering.

But... would (d) ever occur?

• step a. ensures that the array is never empty
• step c. ensures that the user agent finds a suitable URL if there is any
• step b. says that if there is no suitable URL, it is a fatal error and returns failure

Steps c. and b. are complementary, i.e., step d. will never occur...

Shouldn't we say that it is not a fatal error but a warning? I.e., we could modify the steps as:

a. If manifest["conformsTo"] is not set, validation error, set to « "https://www.w3.org/TR/pub-manifest" ».
c. If manifest["conformsTo"] includes the URLs of more than one profile the user agent is capable of processing and/or rendering, set to the first in the array in the case of conflicting requirements.
d. Otherwise, validation error, and set to a profile defined by the URL the user agent is capable of processing and/or rendering.

Shouldn't we say that it is not a fatal error but a warning?

I'm lost. Why would it be a validation error for there to be a single usable profile URL? That's what your third step leads to.

The four possible scenarios are:

• the profile property isn't set.
• the profile property is set, but none of the values are usable.
• the profile property is set and has more than one usable value.
• the profile property is set and has exactly one usable value.

If we wanted to try and compress these, only the first two and last two can be coaxed into similar statements:

• if the profile property isn't set, or doesn't contain any usable values, validation error, set to the default
• if the profile property contains one or more usable value, set to the first.

(But "setting to the first" is awkward terminology when we can't be sure if there is an array of values.)

I also avoided saying that profile has to be a string because there seems to be this idea that a publication might conform to a bunch of profiles at the same time. I'm still not clear how this works in practice, though.

But can you explain how there is a profile of the generic manifest? Where is this profile defined? How does anyone find out what it means? What does a user agent do with it? I still can't wrap my head around what use this default has.

Wouldn't it be better to say that if a publication has no profile or an unrecognized profile, the user agent should still attempt to open the publication as though it were conforming to a profile it is capable of rendering? I'm okay with not having a fatal error, but I don't like this generic profile idea.

Or how about we try digging deeper into when the user agent might be able to continue processing with wording like this:

(§ 2.7 Profile Conformance) Let profile be the profile the manifest conforms to. Set profile as follows:

1. If manifest["conformsTo"] is not set, or does not include a profile the user agent recognizes as capable of processing and/or rendering, the user agent SHOULD inspect the media type(s) of the resources in the reading order to determine if the publication matches a profile it is capable of processing or rendering. If so, validation error, set profile to the matching profile. Otherwise, fatal error, return failure.

2. Otherwise, set profile to the first URL in manifest["conformsTo"] the user agent is capable of processing and/or rendering.

Note
The value of manifest["conformsTo"] could be a string or a list at this step in the process.

I have the impression that our intentions are the same and, actually, we are even saying the same in our versions (e.g., I tried to avoid the term 'profile' in #101 (comment) to avoid questions that you were raising about a default profile).

However... I actually like your last proposal (#101 (comment)). It is concise and straight to the point; I would propose to keep to that one, and remove all the previous attempts from our minds...