-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conformance criterion for UA #270
Comments
I think we need to look into this. |
And, as folks would expect me to say... I think we need to be very wary of specifying UA/RS features. It seems we should specify data, and generally leave it to the UA/RS developers to build good, bad, or ugly features (or lack of features). |
So... a conforming web publication user agent has no obligation to display a publication on the web? A conforming web publication user agent has no obligation to support HTML or CSS? I find this troubling. This means that WPUB could become a formal W3C Recommendation based on two implementations that output the infoset to punch cards, or cross-stitch instructions. |
EPUB does have conformance criteria for reading systems, including things like
|
For the less experienced among us, some context: For a spec to become a formal W3C REC, you have to demonstrate two independent implementations of each feature (which may or may not include punch cards and cross stitch patterns). Problem Statement: The current language in the spec does not require a UA to display the actual content of a wpub. Implementations don't have to do anything except turn a manifest into an infoset. Qualifier to consider: We need to consider where to draw the line in establishing requirements for UA (User Agents)/RS (Reading systems) Proposed solutions: ...? |
The UA conformance section is one of a number of incomplete sections, so if we're arguing it's incomplete we're sort of arguing the obvious. The reason there is only one bullet is because so much of the focus of the specification to date has been on the construction and parsing of the manifest/infoset. We've never sought agreement on anything else. Is it non-contentious that we could add that a user agent also has to be a conforming HTML user agent? There's probably also a bullet about feature support, but we're not far enough along (I don't think) to try and phrase it yet. I'd shy away from statements about "displaying" and "the web", though, as intranets and localhost aren't the web but I don't see why my publication shouldn't work on them. Not every conforming HTML user agent has to support CSS or JavaScript, either. At any rate, I believe the plan was always to circle back to these conformance definitions later once we knew more about what we were creating rather than try to define them up front. |
👍 to @mattgarrish There is another aspect of conformance that is related to the way the manifest is processed: the current text is close to the point where the processor 'just' converts the (canonical) manifest into some data structure, but the process should also be completed (in my view) with a series of statements on the metadata/manifest items. Eg, if an accessibility term is not one of the predefined ones, it must be rejected (ie, removed from the array of terms), etc. I recognize this is orthogonal to the original issue statement, but is also part of the conformance... |
This will be followed up with work by @francofaa and @atyposh on UCR and Affordances. |
At the moment we require that a conforming UA:
"is capable of generating a conforming infoset for a Web Publication."
In my opinion this only implies that the UA is able to parse the manifest and store the information in an internal data structure of its choice. Does this automatically imply any feature or functionality in consuming WPs that would be offered to the user?
My concern behind that question is that formally a conforming UA could just parse and store the data and then implement whatever its developers intend to offer (worst case: even nothing).
The text was updated successfully, but these errors were encountered: