RE: html for scholarly communication: RASH, Scholarly HTML or Dokieli?

Ivan has read my mind, as usual.

I have been working on HTML for Wiley’s thousands of journal articles across many areas, especially hard sciences for about two years. I have also been in the business of creating subsets of HTML. There are a lot of surprises out there. HTML changes rapidly, and the state of the art of scholarly publishing changes constantly. Before we discuss whether we should allow H2-6, we should assess what are goals are as a group, get a handle on leadership (we seem to have a few people at the helm), review some samples, and make sure that we are all looking at the same version of HTML.

Benjamin is working on getting a generic sample of Wiley’s in-progress HTML+ RDFa model to share.

Tzviya Siegman
Information Standards Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Ivan Herman [mailto:ivan@w3.org]
Sent: Sunday, September 10, 2017 3:49 AM
To: public-scholarlyhtml@w3.org; Sarven Capadisli <info@csarven.ca>
Subject: Re: html for scholarly communication: RASH, Scholarly HTML or Dokieli?

I am afraid we are engaging in some sort of theoretical discussion here which will never end: do we want to use the full of HTML5 or do we want to define a smaller structure by restricting to a subset of HTML5? I would think that we would be a bit ahead of this after the experiment Benjamin proposed: let us take a few real articles from various fields and see how the score with the RASH and SH; it will become easier to have an idea.

Maybe one more step would be, for each of those to also see how easy it would be for some of these articles to be formatted via CSS (or maybe CSS+JavaScript) to the formats that are in use (ACM, IEEE, etc). I am particularly worried about the incredible differences in article reference formats out there, and how could one author a paper so that the content could be adapted to any existing requirements (there is a reason why BiBTex is a separate engine to LaTeX…)

I am perfectly aware that some of these formats are a leftover from the ‘print’ world. But an underlying question to part of this debate is whether we want to conduct an evolution or a revolution (for those of you who witnessed the XHTML/HTML5 war back 10 years ago this may sound familiar…). If we talk about a revolution than we can safely ignore that ACM and IEEE formatting habits. If we talk about evolution then, in my view, we cannot…

Ivan

P.S. With my W3C role’s hat put down:-)

---
Ivan Herman
World Wide Web Consortium
Publishing@W3C Technical Lead
http://www.w3.org/People/Ivan/

ORCID: 0000-0003-0782-2704


On 10 Sep 2017, 00:05 +0200, Sarven Capadisli <info@csarven.ca<mailto:info@csarven.ca>>, wrote:

On 2017-09-09 22:48, Johannes Wilm wrote:

The formats that focus on a limited tag-set have been developed already
(RASH and Scholarly HTML) may have just about everything we need
already.
It certainly does not, and that's part of the issue here.

Scholarly HTML doesn't set that constraint. RASH has the following 32
elements:

a, blockquote, body, code, em, figcaption, figure, h1, head, html, img,
li, link, math, meta, ol, p, pre, q, script, section, span, strong, sub,
sup, svg, table, td, th, title, tr, ul

Looking at that list, it seems predominantly a *print first* approach,
not "Web first"! In 2015 it was about 25 elements, and that was
certainly all one needed. So much for that.

The last thing SH would want to respond to the scholarly community is
something like "`video`? Sorry that's not allowed. Please align your
perception of scholarly information on the Web with ours (circa 2017)."

That exact line of reasoning holds true for any given element or
arbitrary constraint on top of the *living* HTML spec.

Again, authors will want to do things beyond what SH could possibly
capture, or the CG can plan for. Plenty of skills in this CG, but let's
not forget that we are only a vocal minority. I suggest that we do not
prematurely think we got scholarly information covered by way of x
elements or whatever.

-Sarven
http://csarven.ca/#i