Scholarly HTML site is up
Peter Sefton
I am cross posting this to scholar...@googlegroups.com
(https://groups.google.com/group/scholarly-html) and Beyond the PDF -
please sign up to the Scholarly HTML list if you're interested in the
work we've been doing on specifying a profile of HTML for the research
object of the future.
I have a post on my blog
<http://ptsefton.com/2011/05/03/scholarly-html-website-up-at-httpscholarlyhtml-org.htm>
explaining a bit about the new site at http://scholarlyhtml.org.
The current plan is to continue developing content for the site in
EtherPad documents hosted by the Open Knowledge Foundation. Les Carr
has already been in contact with me about the page describing the
core, pointing out it needed some opening text to explain what SCHTML
is in relation to HTML - and I have edited the pad to try to deal with
his concerns: http://okfnpad.org/schtml-core
I am already questioning one of the decisions I made, to use asciidoc
formatting. On reflection I think it would be better to try to use
this project to develop at least one lightweight text format tool
chain for creating scholarly HTML, and I'm not sure that asciidoc's
tight coupling to DocBook is going to make that easy to do (I'm
working on a blog post now that explains some of the issues). I now
think we should consider wiki creole <http://www.wikicreole.org/> as a
format that is more in the spirit of Scholarly HTML. Wiki Creole was
developed to create a processor and application independent 'best
practice' common syntax drawing on the large number of lightweight
text formats that have emerged for various purposes. I am interested
to hear what others think about this.
Peter Sefton
Phillip Lord
Peter Sefton <ptse...@gmail.com> writes:
> I am already questioning one of the decisions I made, to use asciidoc
> formatting. On reflection I think it would be better to try to use
> this project to develop at least one lightweight text format tool
> chain for creating scholarly HTML, and I'm not sure that asciidoc's
> tight coupling to DocBook is going to make that easy to do (I'm
> working on a blog post now that explains some of the issues).
I use asciidoc heavily for generating blog posts and, these days,
presentations. I'm not sure that it is tightly coupled to docbook per
se. It is doctrinaire about document structure, though (So, you have to
have a head 2 inside a head 1 and so on).
I've found the format straight forward to use, although occasionally
ugly (perhaps this is because my editing tools are not as good for
asciidoc as they are for other formats).
It is also very extensible; for instance, I added the initial version of
for slidy support
http://www.methods.co.nz/asciidoc/slidy.html
Stuart Rackham, the developer, is also very open and adds new things in
willingly, although carefully.
The extensibility is limited, however. The backend configuration files
are not the easiest thing in the world to work with. And, asciidoc is
basically a big search and replace engine, so you the extensibility is
limited; you can't do arbitrary macro expansion, as you can in latex.
So, you can't include kind of markup in another. For instance...
comes from this source...
[source]
----
include::javascript/hello_world.js[]
----
js-button::hello_world.js[]
where the pointer to the javascript has to be duplicated. You can get
around this, but that requires duplication in the backend configuration;
you can't define a markup which expands into more markup in otherwords.
The only way to avoid doing this is to extend asciidoc itself. Also
messy.
I've been thinking of using something like cheetah as a preprocessor.
This way I get the extensibility, but can carry on using the asciidoc
syntax for the 95% of the document structure for which it works.
> I now think we should consider wiki creole
> <http://www.wikicreole.org/> as a format that is more in the spirit of
> Scholarly HTML. Wiki Creole was developed to create a processor and
> application independent 'best practice' common syntax drawing on the
> large number of lightweight text formats that have emerged for various
> purposes. I am interested to hear what others think about this.
I've never used wikicreole; to me, this suggests something about take up
levels. Good idea but...
All of this is terribly geeky, though. The only people who I know who
are going to go anywhere near this sort of text tool are those who are
already using one (or two, or three!), people who find that
more graphical tools don't work for one reason or another, or people who
need text to work with external tools (like a version control).
Bottom line, lightweight text format tools are good for maybe 2 or 3% of
the population.
Phil
Peter Murray-Rust
An alternative to cheetah is jinja. The advantage of using jinja is that it would let the documents integrate easily with dexy, since dexy also uses jinja.Dexy is a cool new tool for creating documentation that allows "making" docs from combinations of asciidoc, textile, R, python, bash, etc code either as text or as dynamically executed results. Like Sweave but so much better. Easy to create all sorts of enriched documentation, including blog posts, R vignettes, etc.I really like it, and simple integration with Scholarly HTML would be awesome :)
(fwiw I think the dexy developer, Ana Nelson @ananelson, plans to support other templating systems in the future but for now it is built around jinja)
--
Peter Murray-Rust
Reader in Molecular Informatics
Unilever Centre, Dep. Of Chemistry
University of Cambridge
CB2 1EW, UK
+44-1223-763069
Peter Sefton
Re wikicreole - there is little uptake I guess, but maybe that will
change if people choose it for new projects? Anyway, for ScholarlyHTML
if it is to work it will need to integrate with various tool chains.
I guess you're right about the 2 or 3% - but the community working on
ScHTML are for the most part in that group. This is a problem if we
stay there and don't attend to what the the others are doing. In many
disciplines they are using Word - my background is in helping those
people to create quality publications and I will continue to look at
word processor based tools.
So I guess the question with asciidoc is can it be extended to provide
a way for people to create rich semantic HTML that does not get lost
in processing? My understanding, which might be wrong is that EPUB
generation is done via DocBook, so it is possible that some HTML based
semantic encoding would be lost. Not important in the short term,
definitely a concern if we want to have a world where semantic markup
is everywhere. Citations/references and inline metadata will make good
test cases. I would be interested in looking at whether your kcite
work could be extended into a general purpose tool beyond WordPress,
for example.
pt