- From: 木田泰夫 <kida@mac.com>
- Date: Wed, 8 Nov 2023 16:12:30 +0900
- To: Koji Ishii <kojii@chromium.org>
- Cc: JLReq TF 日本語 <public-i18n-japanese@w3.org>
- Message-Id: <E310CF6E-F2B1-447F-9EC6-FB83227BF601@mac.com>
石井さん、 > では、原則、JLTFからの提案やJLREQ/JLREQ-Dは、互換性上の問題は検討せず、互換性の場合がある場合の対応は各WGで、ということですね。 いえ、「提起された問題に対して議論を行い」と書いたように、JLReq TF 内で議論して何らかの返答をするというのは JLReq TF の役目かと思います。ただ、JLReq というドキュメントは実装の問題には立ち入りません。 木田 > 2023/11/08 15:55、Koji Ishii <kojii@chromium.org>のメール: > > 直近でスコープが合致しているかどうかの疑問を感じたのは、約物の配置におけるCSS既定値の議論ですが、和欧間アキも既定動作の変更ですし、今後も他にも出てくると思われるので、議論の土台を確認しておければと思いました。 > > では、原則、JLTFからの提案やJLREQ/JLREQ-Dは、互換性上の問題は検討せず、互換性の場合がある場合の対応は各WGで、ということですね。 > > On Wed, Nov 8, 2023 at 3:38 PM 木田泰夫 <kida@mac.com <mailto:kida@mac.com>> wrote: >> 石井さん、 >> >> >> JLReq TF の主な役目は組版の要求仕様をまとめ、また仕様と実装とのギャップを調べて報告することかと思います。ですので、実装における互換性の問題はまずはそれぞれの実装者の問題であると認識しています。 >> https://www.w3.org/International/jlreq/charter/ >> >> ただ、互換性から来る現状に大きな問題があると考えられる場合には、仕様と実装とのギャップとして報告し、ではどうしよう、という議論が必要になることもあるかもしれません。またはそこまででなくても、提起された問題に対して議論を行ない、何らかの reccomendation を行うのも、専門家をここに集めてあることの良い活用かと思います。 >> >> JLReq / JLReq-d で実装の問題に触れることは、本来の役目ではありません。しかし特に JLReq-d においてはそのような必要性を感じることも出てくるかもしれないと思っています。つまり問題によりけり、case by case だと考えています。 >> >> 具体的にはどんな問題を考えておられますか? >> >> 木田 >> >>> 2023/11/08 15:04、Koji Ishii <kojii@chromium.org <mailto:kojii@chromium.org>>のメール: >>> >>> 先日の議論で、分からない部分があったので、JLTFのスコープを確認させてください。 >>> >>> 特にデフォルトの挙動を変更したい場合においては、WebやEPUBの互換性が課題になる場合があります。 >>> >>> このような場合、JLTFとしては >>> >>> 1. 紙・デジタル全般について議論する場であり、互換性上の制限がある場合には、それぞれのWGで議論するべき。相談には乗るが、JLTFとしての議論をしたり、JLREQあるいはJLREQ-Dに掲載すべき内容ではない。 >>> >>> 2. WebやEPUBはすでに確立されており、膨大な既存こんてんつが存在する。互換性が問題になる場合、それぞれのケースについて事情を考慮し、議論やJLREQ/JLREQ-Dへの記載を含めて考えていきたい。 >>> >>> いずれ、あるいはそれ以外の答えも含め、どのような立場でしょうか? >>
Received on Wednesday, 8 November 2023 07:12:53 UTC