Re: Non-normative?

> On 20 Nov 2018, at 13:21, MURATA Makoto <eb2m-mrt@asahi-net.or.jp <mailto:eb2m-mrt@asahi-net.or.jp>> wrote:
> 
> Ivan,
> 
> It is nice to hear that CSS features do not have to be tested in the CR phase.  I 
> suppose that the hardest part is rendition metadata 
> (https://w3c.github.io/publ-epub-revision/epub32/spec/epub-packages.html#sec-package-metadata-rendering <https://w3c.github.io/publ-epub-revision/epub32/spec/epub-packages.html#sec-package-metadata-rendering>)  
> and the spine element.
> 
> But can a recommendation be published before its normative references 
> become recommendations?

I presume you refer to the CSS features. By default, no, but that is something where some further discussions are necessary with Ralph, too.

Ivan

> 
> Regards,
> Makoto
> 
> 2018年11月20日(火) 20:13 Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>:
> (replaced most of the addresses with the task force mailing list for archival, and added Ralph explicitly because there may be some process issues that he knows much better than I do.)
> 
>> On 20 Nov 2018, at 03:38, Dave Cramer <dauwhe@gmail.com <mailto:dauwhe@gmail.com>> wrote:
>> 
>> This becomes an interesting question about what level of granularity is appropriate for EPUB 3.2 and its tests, and how we react to failures, especially when we are talking about things we don't control, like HTML and CSS. 
> 
> Indeed.
> 
> I think there are several different issues at hand here.
> 
> - The official CR phase of W3C aims at testing the document being developed. In other words, we must test those features and only those features that we have defined: handling the manifest, handling the package structure, handling epub:type values (if it is still normative) etc. It is not part of the CR testing to do anything with features specified by HTML, CSS, SVG, etc.
> 
> In this respect, the CR testing is actually (somewhat) simpler than what we expect epubcheck to do: epubcheck also checks the validity of the HTML content (I presume), which is of course the good thing to do, but that goes beyond what a WG is expected to test. Actually, and for good reasons, epubcheck probably just relies on the HTML validator code, which reflects this duality.
> 
> This also means that features like text-orientation is not under our purview in this respect.
> 
> - What a 'conformant implementation' means is  up to us to define. But I checked the HTML5.2 spec in this respect[1] and it is significant that the conformace requirements for a browser are actually extremely simple compared to the complexity of the spec proper. And for good reasons: nobody really talks about the conformance (or not) of Firefox, Safari, or Chrome: they do or they don't implement a particular feature defined in a W3C standard. After all, that is also why caniuse.com <http://caniuse.com/> is around. I would think it is perfectly fine if we talk about Reading Systems in these terms and we talk about conformance of RS in a very minimal term, referring to structural requirement that we have defined only. And we may need an epub specific caniuse.com <http://caniuse.com/>…
> 
> [1] https://www.w3.org/TR/html51/infrastructure.html#conformance-requirements <https://www.w3.org/TR/html51/infrastructure.html#conformance-requirements>
> 
> 
>> 
>> CSS Writing Modes 3 is part of the CSS Snapshot. You can see test results just for section 5.1 on text-orientation here: http://test.csswg.org/harness/results/css-writing-modes-3_dev/grouped/section/5.1/ <http://test.csswg.org/harness/results/css-writing-modes-3_dev/grouped/section/5.1/>. Only 24 of 54 tests meet CR exit criteria right now. 
>> 
>> If some browsers continue to fail these tests, what does EPUB do? We expect CSS to "just work," but what if it doesn't?
> 
> If a particular browser does not implement a feature, that does not invalidate the browser, does not make it non-conformant, because that is not part of that categorization (see above). Nobody in the community refers to these notion for browsers. RS-s should be treated the same way.
> 
> What is an issue for us (and here is where I need Ralph's input) is how we would exactly characterize our references from a normativeness' point of view. While our reference to HTML is fine (afaik, we always refer to what the latest Rec is), our reference to CSS is via the latest CSS Snapshot[2]. Note that the snapshot lists documents (like the Grid layout) as that are listed as "core" although it is still a CR. That may be a bit messy.
> 
> But, again: the "core" of EPUB 3.2, from a spec point of view, is what we define and not what others do.
> 
> [2] https://www.w3.org/TR/CSS/ <https://www.w3.org/TR/CSS/>
> 
> 
> I hope this helps.
> 
> Ivan
> 
> 
> 
>> 
>> I don't have answers to these questions right now. 
>> 
>> Dave
>> 
>> 
>> 
>> 
>> 
>> On Mon, Nov 19, 2018 at 9:08 PM MURATA Makoto <eb2m-mrt@asahi-net.or.jp <mailto:eb2m-mrt@asahi-net.or.jp>> wrote:
>> Dave,
>> 
>> I am talking about the text-orientation property and its values "Upright" and "Sideways".  
>> These values are ignored for some characters.  The default values as specified in UTS 50 
>> may still differ from what implementations do.
>> 
>> Even if browsers become completely conformant, some EPUB RSs will 
>> be different.
>> 
>> Regards,
>> Makoto
>> 
>> 
>> 
>> 2018年11月20日(火) 10:57 Dave Cramer <dauwhe@gmail.com <mailto:dauwhe@gmail.com>>:
>> Hi Makoto,
>> 
>> Are you talking about the values of the prefixed -epub-text-orientation property? Can you describe the problem more fully? Is there an issue with the prefixed versions not meeting all the use cases, or is there an issue with the full CSS Writing Modes not supporting use cases in browsers? Would a reading system (such as Readium) running as a web app with Chrome 72 and using both prefixed and unprefixed properties fail?
>> 
>> CSS Writing Modes is in CR right now. You can see a draft implementation report for browsers at https://test.csswg.org/harness/results/css-writing-modes-3_dev/grouped/ <https://test.csswg.org/harness/results/css-writing-modes-3_dev/grouped/>
>> 
>> Thanks,
>> 
>> Dave
>> 
>> 
>> 
>> 
>> 
>>  
>> 
>> On Mon, Nov 19, 2018 at 8:42 PM MURATA Makoto <eb2m-mrt@asahi-net.or.jp <mailto:eb2m-mrt@asahi-net.or.jp>> wrote:
>> Dave,
>> 
>> I think that character rotation in vertical writing satisfies all 
>> of your conditions.
>> 
>> 1.  No implementations correctly support all characters commonly used in Japan.
>> 2.  Many EPUBs in the world use character rotation in vertical writing.
>> 3.   Implementations are unlikely to become perfect in the near future, even in the 
>>       CR phase.  (Kadokawa requested Amazon to fix this problem, but Amazon said No.)
>> 
>> Japanese publishers know which character they should avoid.  Thus, they 
>> can live with imperfect implementations., and publish vertical writing EPUB.
>> 
>> Dropping the feature for rotating characters in vertical writing is a nightmare.
>> 
>> I am concerned and continue to wonder whether formal objections are 
>> required.
>> 
>> Regards,
>> Makoto
>> 
>> 
>> 
>> 
>> 2018年11月20日(火) 10:22 Dave Cramer <dauwhe@gmail.com <mailto:dauwhe@gmail.com>>:
>> Hi Makoto,
>> 
>> For this situation to come up, we must:
>> 
>> 1. find a feature in EPUB that has zero or one implementation, and
>> 2. is used in actual EPUBs out in the world, and
>> 3. is then still NOT implemented during the Candidate Recommendation phase of the spec, even though we know it is at-risk and used by existing content.
>> 
>> I don't think this is going to happen. If it does happen, then the feature should simply be removed from the spec. If there is a particular corner of the world that depends on this feature, we have no power to stop them, and they have every right to continue doing something that was already not interoperable. I don't see this as a problem. 
>> 
>> I do find the idea of a "non-normative feature" problematic, and don't think we should do anything like that. 
>> 
>> Dave
>> 
>> 
>> On Mon, Nov 19, 2018 at 7:24 PM MURATA Makoto <eb2m-mrt@asahi-net.or.jp <mailto:eb2m-mrt@asahi-net.or.jp>> wrote:
>> Dear colleagues,
>> 
>> People argued that we only have to make non-interoperable
>> features non-normative.  I am very concerned and considering a
>> formal objection when rechartering happens.  I probably have
>> too many experiences with standardization (more than 25 years).
>> 
>> Frankly, "making features non-normative" is nonsense.  What can
>> be made non-normative is paragraphs, sections, annexes and
>> other components of specifications.  Features cannot be made
>> non-normative.
>> 
>> Probably people intended to make the descriptions of
>> non-interoperable features non-normative.  This is not
>> nonsense.  But it is extremely harmful.
>> 
>> Non-normative descriptions have no impacts on requirements and
>> thus conformance.  In other words, non-normative descriptions
>> can be dropped without any impacts on conformance.  Thus,
>> mechanisms described by non-normative descriptions cannot be
>> used as part of EPUB publications; if an EPUB publication
>> contains such features, it is non-conformant.  (The only
>> exception is the case that a specification allows any
>> third-party extension.)
>> 
>> There is only one way to reformulate non-interoperable
>> features, as I see it.  We can allow conformant RSs to do
>> anything (including nothing) when they encounter such 
>> features.  In other words, their semantics are made 
>> implementation-dependent.  EPUB publications 
>> containing such features are still conformant.
>> 
>> Allowing such implementation-dependency is ugly since it
>> provides no interoperability. But it is often the only escape
>> route, when people understand that some features are
>> underspecified and cannot be fully specified.  One such example
>> is Excel sorting order.
>> 
>> It appears that W3C has not been indulged in such
>> implementation-dependency.  But I guess that the W3C team will
>> forgive us.
>> 
>> Regards,
>> Makoto
>> 
>> 
>> -- 
>> 
>> Praying for the victims of the Japan Tohoku earthquake
>> 
>> Makoto
>> 
>> 
>> -- 
>> 
>> Praying for the victims of the Japan Tohoku earthquake
>> 
>> Makoto
> 
> 
> ----
> Ivan Herman, W3C 
> Publishing@W3C Technical Lead
> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
> mobile: +31-641044153
> ORCID ID: https://orcid.org/0000-0003-0782-2704 <https://orcid.org/0000-0003-0782-2704>
> 
> 
> 
> -- 
> 
> Praying for the victims of the Japan Tohoku earthquake
> 
> Makoto


----
Ivan Herman, W3C 
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
mobile: +31-641044153
ORCID ID: https://orcid.org/0000-0003-0782-2704 <https://orcid.org/0000-0003-0782-2704>