Re: Non-normative?

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
)
and the spine element.

But can a recommendation be published before its normative references
become recommendations?

Regards,
Makoto

2018年11月20日(火) 20:13 Ivan Herman <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> 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 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…
>
> [1]
> 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/.
> 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/
>
>
> 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>
> 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>:
>>
>>> 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/
>>>
>>> Thanks,
>>>
>>> Dave
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Nov 19, 2018 at 8:42 PM MURATA Makoto <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>:
>>>>
>>>>> 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> 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/
> mobile: +31-641044153
> ORCID ID: https://orcid.org/0000-0003-0782-2704
>
>

-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto