Re: JLReq TF meeting notes, 2019 May 21st

Forgot to enclose presentation by Nat. Here it is.



> 2019/05/24 20:38、Yasuo Kida <kida@mac.com>のメール:
> 
> JLReq TF meeting notes
> 2019 May 21st @ MediaDo Holdings from 10 am to 2 pm JST (4 hours!)
> 
> Attendee
> Kobayashi, Tatsuo
> Kobayashi, Toshi (Bin-sensei)
> McCully, Nat (online)
> Murakami, Shinyu
> Murata, Makoto
> Shimono, Atsushi
> Tajima, Jun
> Takase, Hiroshi
> Kida, Yasuo
> Meeting notes
> Welcomed Tajima-san
> of course everybody knew him already
> 
> Updates on JLReq update (Shimono-san)
> Consensus
> This update is not a new revision, meaning for stability sake we should limit changes to fixing errors and maintenance work. Improvements will be made in the 3rd revision in the future.
> The page will open in English by default, and allow easy switching to Japanese, and "all" for people who want to check translation.
> Discussions based on a summary Shimono-san sent on 5/30 "current status on JLReq document errata”.
> Let’s integrate items in section 1 and 2. (Shimono-san)
> Section 3 need a translation check. There is another in section 4. (Nat)
> Discussions on some items in section 4 and 5 as regard to fixing errors vs improvements. A consensus was made that what we should focus on fixing errors for this update.
> Other
> Bin-sensei handed source of all images used in JLReq to Shimono-san.
> Action items
> Shimono-san will integrate fixes.
> Nat will check translations.
> 
> Making progress on ruby (Murata-san)
> Murata-san summarised the situation around ruby. The situation on the ruby support has not changed for 20 years. There are confusions due to two separate standards. The support from browsers fall short of requirements from publishers. Despite the situation however publishers are unwilling to support the efforts and cost of pushing it through (probably because ebooks are not yet their main business).
> Discussed possible approaches but no specific conclusions here.
> Features mentioned include (just examples): add support for rb tag in WHATWG spec, simplification of W3C specification and unification with the WHATWG spec, support for centred position, controlling space between the base characters.
> Ruby is also important for universal access (what’s missing for this purpose?)
> Some of the issues could be relieved by developing a guideline?
> Ruby on both sides - the market too niche and small. Is it necessary for the future of e-publishing?
> APL is working on a proposal for simplified ruby spec, which is a possible contents of JLReq 3rd revision.
> 
> Gap Analysis: Comparison of the gap analysis with other requirement lists (Murakami-san)
> Murakami-san developed the comparison chart and sent to the list on 5/16 “各Gap Analysis調査項目の比較表”.
> The coverage concerns cleared by the comments from Richard (in a mail on 5/20 in reply to the meeting agenda). He clarified the intention of the use of the second and third digits of the Gap Analysis section numbers. In short the top level structure uses up to the second level digits (e.g. 3.10), and ones with third level digits are subsections that describes specific issues, and thus they are not comprehensive.
> As mentioned below the chart Murakami-san developed serves as a good start of our task analysis.
> 
> Reviewing a proposal from Nat (Nat)
> Nat prepared a short but an excellent presentation describing how JLReq could be improved.
> It puts developers as centre of the readers. Most of them are familiar with Western line layout and the line layout engines on the platform and the web, but not with Japanese line layout. The Japanese line layout contains some unique concepts that are subtle but critical. The current document however takes them as granted and does not explain them in details and how they are important. He proposed a document that would fill the gap.
> Agreement is that his proposal will be one of the framework of the next revision of the JLReq.
> Action items
> Kobayashi-san will talk to Richard. (done)
> 
> Gap Analysis: next steps - task analysis
> Gaps can be categorised as below in terms of the nature of the required work. As the first step we want to analyse requirements in JLReq and categorise them.
> The corresponding CSS specification does not exist, or still under development.
> The CSS exists, and the test cases exists. We can identify issues by running the test.
> The CSS exists, and there is no test cases yet. The test case needs to be developed.
> As Murakami-san's chart already link requirements and related CSS, it is an excellent start for this task analysis.
> Action items
> Murakami-san will update the chart based on the JLReq requirements chart and using the Gap Analysis’s top level structure.
> Shimono-san will check which css already has test cases.
> 
> Items we could not cover at this meeting
> We will discuss them at the next f2f meeting.
> How we can gather feedback from wider audience
> Tajima-san reported that he started gathering feedback using his twitter.
> JAGAT XML publishing subgroup is working on compatibility check between EPUB readers. How we can take advantage of this work?
> 
> Next meeting
> Will be f2f again. Kida to setup a date.
> 
> //