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


I referred to RASH and SH in my previous mail, and I am happy to add dokieli patterns to the lot. My main point was: I think we need comparative data which we do not really have. (Note that I do not have any take in any of these formats, i.e., I do not really care which one comes out as the most appropriate one!).

As for Javascript: I may not have been clear. Of course I would count on CSS to cover the different formats, without the need for anything else. The point where Javascript _may_ come into the picture is handling the reference formats although Johannes’ approach of using some sort of an off-line processing like Bibtex or other processors based on CSL (no Johannes, I am not really familiar with it, b.t.w., thanks for point that one out) may be also a reasonable approach.


Ivan Herman
World Wide Web Consortium
Publishing@W3C Technical Lead
ORCID: 0000-0003-0782-2704

On 10 Sep 2017, 11:36 +0200, Sarven Capadisli <>, wrote:
> On 2017-09-10 09:49, Ivan Herman wrote:
> > 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…)
> Hi Ivan,
> have you come across dokieli?
> Allow me to introduce it to you in context of CSS. First, see some of
> dokieli's HTML patterns:
> It is used for the following different kinds of documents, all with
> different primary stylesheets (including print). Alternative stylesheets
> can be triggered from the dokieli menu or through supporting
> user-agents. There is *no* JavaScript requirement for the user-agent to
> get a hold of the "data".
> Articles:
> * (scholarly article with dynamic annotations)
> * (a pretty blog post)
> * (a webpage)
> * (another webpage)
> * (a W3C specification)
> * (a thesis chapter)
> * (a workshop proceeding)
> * (call for "papers")
> * (ACM Authoring guidelines)
> * (Springer/LNCS)
> * (Ireland's open data strategy)
> Annotations:
> * As you well know examples in
> derived from dokieli's patterns.
> Notifications:
> * eg.
> Plenty more at:
> with different scholarly articles containing various scholarly information.
> Happy to report that we've covered a wider range of "scholarly
> information" than anything else on the table here. If that's an
> incorrect assumption, people can come forward with URLs to existing work.
> So, are the HTML patterns documented flexible enough to handle different
> cases, including scholarly information? Evidence suggests it to be the
> case. Happy to improve where necessary as always. It is not bullet
> proof. The patterns have come to a point (certainly not the end) where a
> range of things can be expressed without arbitrary or artificial
> constraints set. So, I'm having a hard time buying the argument for any
> subsetting unless one has the intention for the information to work
> *only* under certain 1) tools and 2) versions - let's face it, the
> minute we draw the line what's allowed and not allowed, that has to be
> dealt with straight on.
> For dokieli (in case the /docs is a boring read, nor do I expect anyone
> to read it, ... at the risk of repeating myself):
> * Information is human and machine-readable to the greatest extent possible.
> * Consuming core information does not require JavaScript and gives the
> lowest barrier for any consuming agent. Heck, try it out with links/lynx
> and compare it with whatever is brought to table in this mailing list.
> * dokieli's intention is to allow the expressing HTML as accurately as
> possible (either by hand or as much as the UI allows), and put focus on
> RDF(a) for data/information exchange.
> What do the alternative "formats" do beyond *only* working with the
> frameworks they are capable of working within? Not human and
> machine-readable as they could be, that's for certain, in my opinion.
> If you are all stuck on having a "formal" "format" or whatever, I'll
> write a grammar for it and we can discuss that. How about that?
> PS: I sincerely apologise for the repetition (and probably the tone),
> but I feel that I'm probably not making my points clear enough. So, I
> guess I'll back off the mailing list "for a bit" :)
> Bon weekend,
> -Sarven

Received on Sunday, 10 September 2017 10:33:01 UTC