- From: Florian Rivoal <florian@rivoal.net>
- Date: Tue, 1 Dec 2015 15:18:57 +0900
- To: Robin Berjon <robin@berjon.com>
- Cc: public-scholarlyhtml@w3.org
> On 01 Dec 2015, at 13:13, Robin Berjon <robin@berjon.com> wrote: > > How do you prefer to organise? Here are some proposals: > > • We use a repo on GitHub and largely discuss through issues (at least > for the concrete stuff). We can ask for w3c/scholarly-html and publish > it off there. An alternative is spawning a new org, or creating a team > in another one (we can do that under the scienceai org if you prefer > that, but we don't want to make a landgrab). No strong preference. > • I would suggest we use ReSpec as the format. We could also use the SH > as defined by itself but the problem with that is that every time you > change a definition you have to edit the parts of the document that use > it. We just did that... it's not always fun. I'm partial towards bikeshed, but ReSpec is fine. > • Contributions should be made ideally through PRs more than through > discussion — it makes for more concrete discussions. At the very least, > if discussion then trying to root it is best. For detailed points, yes. For high level discussions, I prefer mailing lists. > • Should we start in stages, first building the HTML structure, then > overlaying semantics, etc. or should we do all at once? I reckon we > might get easier consensus if we move incrementally but that's just a > gut feeling. Not sure what you mean. How can we decide on the markup first without considering whether that markup is suitable for the semantics we want it to cary, or for the styling we'll want to apply to it? > • We should pay particular attention to interaction with > implementations. I know that we have tools that work around our SH, > notably a parser, a set of React components that output it, parts of a > common stylesheet, and ideas about validation and the such. Assuming we > can all reach some rough consensus we'd certainly like to converge them > on the common format. Are there any other consumers/producers here? Vivliostyle technologies are not currently SH aware, but over time that may change. We will certainly want to make sure that at the very least our tools play well with SH, and we are also likely to prioritize implementing (and/or pushing for standardization of) CSS features that are relevant to SH. As understanding the specialized semantics may help offer a specialized (and better) reading experience, we may eventually become SH aware (and not just SH friendly), but that is for the future. - Florian
Received on Tuesday, 1 December 2015 06:19:26 UTC