- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 2 Nov 2018 11:38:55 +0100
- To: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
- Cc: W3C Publishing Business Group <public-publishingbg@w3.org>
- Message-Id: <FBE2B0E0-B9B9-4351-A342-4ACD632F299A@w3.org>
> On 2 Nov 2018, at 05:19, MURATA Makoto <eb2m-mrt@asahi-net.or.jp <mailto:eb2m-mrt@asahi-net.or.jp>> wrote: > > > > 2018年11月2日(金) 0:35 Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>: > Makoto, all, > > I think there are some misunderstandings about the W3C process. Let me try to dissipate some of those. > > First of all, the WG will have defined what exactly a "feature" and an "implementation" means; let me not go there now, that is a separate discussion. With that being said: > > - There is no requirement that there should be at least two implementations implementing _all_ features. While it would of course be great to achieve that, this is not required. > > - The requirement is that _every normative feature_ must be implemented by at least two implementations on a feature-by-feature basis. If feature X is only implemented by UA "A" and "B", while feature Y is implemented only by UA "C" and "D" (ie, not by "A" or "B"), then both X and Y remain normative features of the standard. To take your example below, if a specifically Japanese feature is only implemented by two Japanese RS-s and not by the well-known ones used elsewhere: it is all right. That feature stays. > > > Then, all features in the EBPAJ profile will stay hopefully. I know > that even the tiny EBPAJ profile is not free from interoperability > problems (especially character orientation in vertical writing), but > if we choose two implementation for each character, they should > exhibit the same behaviour. > > - If a feature does not pass the bar, ie, is only implemented by one single RS and not by anybody else, we are still not under obligation to "eliminate' from the specification, only to mark it as informative and not normative. > > > I do not understand. Consider an EPUB publication containing such > a mechanism. Is it conformant? We have not defined what it means for an EPUB publication to be 'conformant'. So far, as far as I know, the tool for conformance was epubcheck. We have the liberty to define that. That being said: I think we are really discussing a very peculiar edge case. If there is a feature in EPUB 3.2 that is implemented by one and only one (or worse: none!) Reading System, we should have serious thoughts about the general usability of that feature. We can/should decide that on a case-by-case basis because, I would hope, it would be an extremely rare case, possibly non-existant… Ivan > If it is, isn't the mechanism normative? > We can lift requirements on RSs but cannot make the mechanism > informative. > > Regards, > Makoto > > I hope this helps. > > Ivan > > > >> On 1 Nov 2018, at 15:21, MURATA Makoto <eb2m-mrt@asahi-net.or.jp <mailto:eb2m-mrt@asahi-net.or.jp>> wrote: >> >> Liisa, >> >> 2018年11月1日(木) 22:47 McCloy-Kelley, Liisa <lmccloy-kelley@penguinrandomhouse.com <mailto:lmccloy-kelley@penguinrandomhouse.com>>: >> Makoto- >> >> >> >> I don’t think that we disagree, I just have a very positive outlook that our testing will prove that we won’t need to have that discussion. >> >> >> I think that we do disagree. I am quite sure that some features of EPUB 3.2 >> are not supported by any RSs. I also think that some advanced >> features of vertical writing (e.g., tatechuu yoko and handling of character >> orientation) are not supported by those RSs which are not commonly used >> in Japan. Will such features be eliminated from EPUB 3.2? This worry >> is already a showstopper for Japanese users. >> >> Side note: I know that some EPUB3 publications are dedicated to iBooks. >> If we drop non-interoperable features related to scripting, will such EPUB >> publications become non-conformant? >> >> Regards, >> Makoto >> >> >> >> >> Can you think of any EPUB feature that is only used in one reading system in Japan and no other? >> >> >> >> Liisa >> >> >> >> >> >> From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp <mailto:eb2m-mrt@asahi-net.or.jp>> >> Date: Thursday, November 1, 2018 at 9:37 AM >> To: W3C Publishing Business Group <public-publishingbg@w3.org <mailto:public-publishingbg@w3.org>> >> Subject: Re: [External] My opinions about the future of EPUB 3.2 >> Resent-From: <public-publishingbg@w3.org <mailto:public-publishingbg@w3.org>> >> Resent-Date: Thursday, November 1, 2018 at 9:36 AM >> >> >> >> Liisa, >> >> 2018年11月1日(木) 21:52 McCloy-Kelley, Liisa <lmccloy-kelley@penguinrandomhouse.com <mailto:lmccloy-kelley@penguinrandomhouse.com>>: >> >> Makoto- >> >> >> >> I think we need to do the testing to see if there are at least 2 instances somewhere in the world of support for each individual EPUB 3.2 feature. I suspect that there are. That is what I understand to be needed in order to move 3.2 to a rec track and then on to ISO. Let’s get through this and see where we are before we scare people that things might get cut. >> >> >> >> >> >> I am afraid that I have to oppose. No matter how non-interoperable >> >> EPUB 3.2 is, I would like to bless it as a REC. Eliminating >> >> non-interoperable features from 3.2 is not attractive to Japanese >> >> EPUB 3 users. >> >> >> >> Regards, >> >> Makoto >> >> >> >> >> >> I suspect the harder bit for many of us is some of the base HTML/CSS stuff that isn’t spelled out in the 3.2 spec because it is assumed, but is still spotily supported across reading systems. Crazy little things like first letter or first line styles, which work much of the time, but not always and cause more work and compromise and trial and error for publishers to understand how they fail and where. >> >> >> >> The thing I’m looking forward to with all of this is the transparency we are trying to bring to the spec and its implementation in all the places we need it to work, not just browsers. I believe that is going to help all of us to get to a much better place of “Don’t mess up!” and even improve significantly on where we are now. >> >> >> >> Thanks so much for checking in with your colleagues. >> >> >> >> Best, >> >> >> >> Liisa >> >> >> >> >> >> From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp <mailto:eb2m-mrt@asahi-net.or.jp>> >> Date: Wednesday, October 31, 2018 at 7:50 PM >> To: W3C Publishing Business Group <public-publishingbg@w3.org <mailto:public-publishingbg@w3.org>> >> Subject: Re: [External] My opinions about the future of EPUB 3.2 >> Resent-From: <public-publishingbg@w3.org <mailto:public-publishingbg@w3.org>> >> Resent-Date: Wednesday, October 31, 2018 at 7:50 PM >> >> >> >> Folks, >> >> >> >> Rick wrote: >> >> >> >> The proposals (to create detailed compliance levels in the spirit of the work done for WCAG, and to ‘fix the broken contract that bugs are evidence of’) are excellent, and could build on top of a 3.2 rec track specification. >> >> I also would like to separate EPUB 3.2 and compliance levels. >> >> >> >> Yesterday, I spoke with some Japanese involved in >> >> e-publishing business. In Japan, thanks to the small >> >> profile of EBPAJ, EPUB 3 works. Thus, nobody is >> >> interested in eliminating non-interoperable features >> >> from EPUB 3.2. A common reaction is "Don't mess up!". >> >> >> >> Therefore, I would like to bless EPUB 3.2 as a REC no matter >> >> how non-interoperable it is. But I do see advantages of >> >> an interoperable subset (or compliance levels). Thus, I >> >> welcome a separate specification (possibly a REC) for >> >> such a subset. >> >> >> Long time ago, W3C create WebCGM as a REC. It >> is a subset of an international standard, >> >> ISO/IEC 8632:1999(CGM). I am wondering if we >> >> can do something similar. >> >> >> >> 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>
Received on Friday, 2 November 2018 10:39:00 UTC