Closed pes10k closed 2 years ago
palemieux
commented
2 years ago Error reporting seems entirely dependent on the specific application, e.g. a browser-based user-facing application vs a micro-service. Maybe more to the point, the IMSC HRM errors will not regularly (or perhaps ever) be reported by user agents, instead they will be reported by authoring tools and/or services -- maybe that should be stated?
nigelmegitt
commented
2 years ago This topic may not be intuitive for new readers.
§4 says:
A sequence of consecutive intermediate synchronic documents conforms to the Hypothetical Render Model if is processed without error as defined in § 6. General.
Then §6 and §9 each define one such error that can result.
This use of the term "error" might be misleading to people used to the term's usage in other context but is functionally fine. I thought about proposing to change the term, but really I think it's fine. However a separate "error" section to explain the model might be helpful.
For example, although only one error is needed to demonstrate non-conformance, there's no requirement either to stop on an error or to continue looking for more errors.
they will be reported by authoring tools and/or services -- maybe that should be stated?
@palemieux seems like a good idea to me. Those tools may of course be applications that run on a user agent. If nothing else, we could say that there's no need to propagate the errors beyond the HRM - if a validating processor checking for conformance to the HRM finds an error, it does not need to raise it further, but could simply report false as the result of the analysis, or true if no errors were found.
We can also state that there's no format defined for reporting the set of encountered errors.
pes10k
commented
2 years ago Thank you for the above discussion. Yes, if the proposal does not define any runtime / execution time errors, that would be useful to explicitly state. However, it seems like some of the conditions that would trigger an error state could occur at runtime (for example, if the "Presentation Compositor to fail to complete painting pixels for En before the presentation time of En"), no?
nigelmegitt
commented
2 years ago @pes10k I think there may be a misunderstanding of what the IMSC-HRM does.
I would expect that all errors defined in the imsc-hrm spec occur at runtime / execution time; however the result of such an error being encountered is that the implementation can report that the sequence of ISDs does not conform to the HRM. It would be absurd to implement an imsc-hrm validating processor that could not handle this unsurprising outcome.
Whether or not there is time to complete painting pixels before the next ISD is a static computation rather than an effect that will be encountered by an imsc-hrm implementation because it simply does not have enough time. The execution time of the imsc-hrm processor need not be related to how long it takes an actual IMSC presentation processor to render the ISDs themselves.
For example, let's say it takes some real world IMSC rendering processor 0.4s to render an ISD, and that ISD needs to be displayed 0.3s after the previous one. In that case, some audience-impacting undesirable behaviour will occur, somehow.
However, that is a different task from the one that an IMSC-HRM processor would perform, which is to statically analyse the ISDs: if the HRM computes that the hypothetical rending duration is 0.5s and the time available is 0.3s, it can simply report that the sequence does not conform to the HRM: no pixels need to get rendered to make that computation. Furthermore, completing that calculation is likely to take a fraction of the IMSC rendering time.
nigelmegitt
commented
2 years ago @pes10k Does the proposal at #40 address your concerns in this issue?
npdoty
commented
2 years ago The proposed descriptive introduction in #43 is helpful in clarifying the use cases, and might give reviewers better insight, including for issues #30 and #31 as well.
If validation of an IMSC document against an IMSC-HRM is exclusively done as part of the authoring and validation process, rather than as part of the user-facing rendering, I believe that significantly limits the scope of privacy or security concerns.
Describing an error model and defining how errors should be handled is generally a best practice for the Web because we have learned that lacking guidance on what a processor of a document should do in the case of errors can lead to a lack of interoperability (e.g. some authors start to rely on the failure behavior of a particular processor) or to security or privacy risks (e.g. undefined behavior after an error in the document could reveal characteristics of the device that encountered the error).
I could see some of those lessons being relevant even in authoring-specific contexts. If a processor only reports the first error, it may take longer or lead to confusion among authors about the other errors in the document where complexity violates the model. If a processor tries to report all errors, might there be a cascading issue, where an overrun in timing in one section leads to reporting of errors for subsequent sections? If a processor stops on the first error, the creator of the IMSC document might learn where the error happened (or something about the HRM being applied) in the pattern of what remote resources were loaded.
Not specifying how errors are handled or reported could have limited usability or privacy issues for parties in the authoring process or at least we can give less certainty about those implications as part of this review. But I think the potential privacy or security implications of inconsistent error handling is greatly reduced if this is only used at the authoring stage and not by the user-facing renderer.
pes10k
commented
2 years ago @nigelmegitt I do not think the issue has been resolved yet. As best I can tell from re-re-reading the proposal, there are certain kinds of error-states that can not be determined at author (or publish) time. For example, the spec defines an error state where the buffer has grown beyond the "Normalized Glyph Buffer Size". Since
i) the size of the buffer depends (in part) on the glyphs being used, and ii) which glyphs being used can't be determined at author time (since how the device should interpret a font-face instruction is undefined)
it seems that, as best I can tell, there are at least some error states (and so errors raised) that can only be dealt with at runtime, on the device. If that is the case, then it is important to know what the device should in those cases that it SHALL raise an error.
@nigelmegitt, to try and best get this to resolution, can you confirm if the above is correct, and there are some error states that can only be determined at runtime?
nigelmegitt
commented
2 years ago Sorry @pes10k, I think you have misunderstood the specification - I can confirm that your conclusions in https://github.com/w3c/imsc-hrm/issues/29#issuecomment-1068429760 are in fact false.
The definition of "glyph" used is entirely independent of any font face instruction and is deterministically computable from the document contents alone. There has been some discussion of renaming the term to something less easily confused with glyph as defined elsewhere, and we may yet do that.
There is no part of this specification that specifies or requires (even as a MAY or SHOULD) that the processer fetches any resource external to the document being processed. There are no (intended) error states that can only be dealt with at runtime and that may differ from device to device.
pes10k
commented
2 years ago Thank you for the clarification @nigelmegitt.
The thing thats still twisting me though is that I still don't understand whats supposed to happen if, say, the pixel height of a rendered glyph doesn't match the height the proposal seems to anticipate, based on the fontSize instruction. Or if the complexity of rendering the selected glyphs takes longer than the amount of time required by the proposal, etc.
More broadly, I don't understand whats supposed to happen at runtime, if the things assumed (or required?) by the proposal aren't possible or don't hold.
That said, im okay to close this out. I'd recommend the group:
That said, i appreicate that this review, and straightening this out has taken a while. I'm happy to close the issue now, and thank you for bearing with us
This issue is part of the PING privacy review w3cping/privacy-request#65
There is normative text describing cases where errors must be raised (for example "It SHALL be an error for the Presentation Compositor to fail to complete painting pixels…"), but the document doesn't define what this means. How is the error raised? Which parties on the page (if any) are able to access it? How can the page / application respond to the error? Etc.
Unless the error model is defined, its not possible to fully evaluate the privacy-implications of the proposal. If the document is going to include error conditions, it's necessary to also define the scope, lifetime, visibility, and information contained in those errors (or if the intended error model here is defined elsewhere, with links to that definition).