Missing conformance criteria around item properties?

[iherman]

The content document says that the author MUST set the scripted item property if the content document does indeed have script usage (or other things). However, there is no word in the RS document (or I did not find it) what happens if the author forgets about this.

If there is a MUST on the author's side, I would expect the RS to ignore the script in the content document. However, if, in fact, the usage of that scripted property has been introduced to "help" the RS to optimize in some way or other, then this property is more a "hint" rather than a processing instruction. If so, isn't it better to say that the usage of that property is RECOMMENDED rather than MUST?

Similar considerations may be valid for other item properties, e.g., svg

[mattgarrish]

However, if, in fact, the usage of that scripted property has been introduced to "help" the RS to optimize in some way or other, then this property is more a "hint" rather than a processing instruction.

Yes and no, I guess.

Some reading systems that support scripting might only enable support if the property is set, but it's not a requirement that reading systems toggle support based on the presence of the property. Scripting might always be enabled.

The reason for it being a "must" is that if you don't set it, those reading systems that only enable scripting based on the presence of the property, won't. Not a surprise authors would want.

So even though they are technically hints, dropping to a recommendation could lead authors to think it's not that important to set.

But I guess you can always squeeze out a reading system requirement along the lines of: "If a Reading System supports scripting, it MUST ensure that scripting is enabled for the designated EPUB Content Document."

I'm just not sure how well that pattern of requirement holds up when you get to remote-resources, for example. A reading system might only allow selective retrieval and still be conforming.

[bduga]

I agree with Matt, the current requirement makes sense and loosening it could be dangerous.

[iherman]

I agree with Matt, the current requirement makes sense and loosening it could be dangerous.

I have no problems keeping the requirement but my original comment still stands: if this is a MUST, then we must also specify how the RS reacts in case the author does not properly set the item property and has scripts nevertheless.

[bduga]

We can add something, but I also think the requirement will be one of @dauwhe's favorite things - an untestable assertion. "When missing and scripts are present, a Reading Systems [MAY|MAY NOT] execute them".

[iherman]

"When missing and scripts are present, a Reading Systems [MAY|MAY NOT] execute them".

Except if I say "When missing and scripts are present, a Reading Systems MUST NOT execute them". I am not saying that this is what we should do (it may be too draconian) but it is an option we may have...

[mattgarrish]

In what scenario does anyone put in scripts, mathml, remote resources, etc. but not want or expect them to render, though? That seems to be the only thing we're setting up here, as in all other cases the reading system will already do the right thing (either handle them in all cases or selectively enable support per publication/document).

I agree it's not ideal that we burden authors with a reading system optimization -- in hindsight, these flags probably should have been limited to optional support features, if created at all -- but it's too late to go back on that part now.

It feels a bit like we're creating reading system requirements for the sake of reading system requirements when we have plenty of other instances of authoring requirements that don't have reading system corollaries (all the required metadata, for example).

[iherman]

I agree it's not ideal that we burden authors with a reading system optimization -- in hindsight, these flags probably should have been limited to optional support features, if created at all -- but it's too late to go back on that part now.

… and, obviously, we should not remove those now. What I am questioning is that these flags are a MUST. If we are talking about the author, sort of, helping the RS to do a more optimal job, then this should be maximally a SHOULD or even a MAY. That does not lead to backward compatibility issues but would avoid perfectly functioning and correct EPUB instances to be refused by, say, epubcheck.

[llemeurfr]

Could it be solved with a SHOULD on the authoring side and rely on a simple definition on the RS side, like "The scripts flag signals the presence of scripts in the content and allows the RS to activate scripting on demand". Not really a requirement (I agree with Matt that creating requirements for the sake of creating them is cumbersome).

[mattgarrish]

If we are talking about the author, sort of, helping the RS to do a more optimal job

But that's not what we're doing. We're ensuring the author doesn't fall into a trap of thinking their content will work when the flags aren't set.

If we only recommend, how does the author benefit from not setting these flags? That's my concern here. Even if they only intend their content to work on a single device, which I'd hope those days are over, they still have to know in advance whether setting the flag or not will be problematic. There aren't going to be that many publishers with this knowledge. We don't even know how many systems are affected by which flags.

(It would be interesting to find out if any of them beyond scripting are actually used, as I'd like to see the number pared down, but I'm pretty certain scripting has been established in past surveys as in use.)

[iherman]

Well, maybe we should ask around whether RS-s actually look at this flag in the first place, and if yes, why and how.

[iherman]

The issue was discussed in a meeting on 2021-01-07

List of resolutions:

• Resolution No. 1: Close Missing conformance criteria around item properties? #1422, leaving the language in the content document as is.

View the transcript

2. Missing conformance criteria around item properties.

See github issue #1422.

Wendy Reid: essentially, the content side of the spec says that authors must set the scripted property on items, but there's no equivalent language in the RS side of the spec.
… no prescribed behaviour for what RS should do if the property is missing.
… applies to other properties, but scripting is a good example of this discrepancy.
… can either leave the RS spec as is, or we can add some language to prescribe behaviour if this is important.

Garth Conboy: in another discussion, about I believe MathML, I think we ended up saying that these properties are useful to RS, but not something they can absolutely rely on.

Wendy Reid: there was a suggestion in the issue that if the property is absent, the RS could in theory choose not to enable the script, but this goes against the expectations of authors is seems counter productive.

Brady Duga: i can see how RS could use the presence or absence of these properties to modify RS behaviour.
… it is not trivial to ask an RS to just look at a document and determine for itself whether it has scripts or not.
… so that's a point in favor of leaving it.

Ben Schroeter: reviewing the differing positions as presented in the issue.
… i think the rub is whether we should require the authoring requirements have a 1-to-1 correspondence to the RS requirements.
… and i don't think we've done that.

Wendy Reid: leaning towards leaving it as is.
… with the proviso that we can come back to this after we have the larger discussion about scripting.

Proposed resolution: Close #1422, leaving the language in the content document as is. (Wendy Reid)

Shinya Takami (高見真也): +1 to leave it as is.

Ben Schroeter: +1.

Garth Conboy: +1.

Ben Schroeter: +1.

Brady Duga: +1.

Matthew Chan: +1.

Toshiaki Koike: +1.

Shinya Takami (高見真也): +1.

Wendy Reid: +1.

Masakazu Kitahara: +1.

Resolution #1: Close #1422, leaving the language in the content document as is.