Hi all, I'm writing to Council because I need to get some clarity on what Council is aiming at with regard to the ruby markup proposal and the upcoming release. My initial understanding, and the work Syd and I have been doing, was based on the idea that we would really like to get a basic implementation of the new elements into the schema, along with a simple section for the prose chapter, in time for this release; that would allow the Japanese users in particular, who initiated the work, to get started with the markup and begin to work out some of the edge cases. However, the work on the ticket and the repo has become increasingly complexified; Duncan has submitted a set of cases that would stretch the initial implementation considerably and require a much-expanded prose section with many more examples, and this could not be ready for the upcoming release. My personal view is that these cases could be submitted as feature requests for further exemplification and expansion of the chapter prose, which we will need to do anyway, after the initial release, but Duncan is quite determined that he doesn't want to do that. There are also various discussions about multiple methods for doing stand-off ruby markup, some of which look quite flaky to me, and which I wouldn't really want to recommend in the Guidelines; but I'm not a content expert and don't have much authority to wield. As always, there is a lot of tension between the need for the Guidelines to provide straightforward, generic recommendations and the desire for people to see their own preferred approaches sanctioned and exemplified. I need to have something ready for the Council meeting on Saturday, so I'd like to get Council's view on what we're aiming to do right now. I think our options are: 1. Add only the new elements to the schema, with full Spec files and basic examples in them, but without any prose section in the Guidelines. 2. Add to #1 a relative short and straightforward introduction in the prose, with some basic worked examples, but no complicated edge cases, at the same time soliciting feature requests for further work. 3. Give up on getting anything into this release, and instead adopt a working-group approach to build a complete solution before we put anything into a release. My personal preference is for #2, but I don't think it's a decision I can make without Council's backing. Cheers, Martin -- ------------------------------------- Humanities Computing and Media Centre University of Victoria mholmes@uvic.ca