Kevin and thread,
I think this is very interesting.
Apart from platform I think the main difference you see between the
latest static site generators and XSLT-based solutions (that have been
around in various forms since prehistoric times) are the way(s) the
source data is encoded and managed.
Hugo (the site generator I have looked at most closely) accepts a
combination of markdown (i.e., HTML via syntax sugar) plus YAML for
metadata. This can be very nice and lightweight especially for a
certain user base and as long as things are simple. It lends itself to
simple web-based UIs and workflows -- or hacking at in a text editor
-- which is part of its appeal.
The classic XSLT-based solution, of course, typically requires a
controlled XML input.
In part because many web developers would rather postpone certain
modeling issues -- and that's not always such a bad idea, or not
obviously -- they are always going to be reluctant to think about XML
-- whereas markdown+YAML is fashionable (and why not).
However, to see that XML-shy web developers are suddenly keen on
off-web processing environments (which is essentially what static site
generators amount to) as viable publication channels -- heh. The world
has always been bigger than the web and still is. Part of what makes
XML a work of (collective) genius is that it offers a solution for an
off-web problem in a may-happen-to-be-the-web environment. Static site
generators offer a solution to a web problem (the pains of site
maintenance) using a not-web-this-time technology stack.
And yes, this makes it the same solution as a
wasn't-the-web-back-then-either technology stack that has been doing
this for decades (such as ones familiar to Ken and Eliot, for
example).
Cheers, Wendell
On Mon, May 2, 2016 at 2:44 PM, Kevin Veroneau kevin(_at_)veroneau(_dot_)net
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Thanks Eliot, that is the best answer, and it fully makes sense.
However, I should point out that a static site generator could be based on
XML/XSLT, and still be user friendly. I have nicely integrated both
Markdown, and Highlight.JS into XML/XSLT with no difficulties. I created
specific XML tags, which in turn generate the required HTML to render the tag
contents as either Markdown or Highlight.JS. It's an absolute marvel, and
makes writing technical documents a breeze. The only thing missing is an XML
editor of sorts to make editing the documents easier.
Eventually I plan on releasing a static site framework based on XSLT, which
would nicely format XML documents. I like the fact, that for XSLT, there's
no post processing required before publication of the site or documents. A
static site generator requires all the HTML files to be regenerated and
uploaded each time.
Original Message
From:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com
Sent:May 2, 2016 9:17 AM
To:xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Reply-to:xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject:Re: [xsl] XSLT or static site generator
On 5/2/16 9:22 AM, Eliot Kimber ekimber(_at_)contrext(_dot_)com wrote:
Many of the documentation Web sites and online help for the products you
know and love are generated from DITA XML, including Oracle, IBM, Adobe,
Cloudera, Oculus, Nokia, and many many others (those are just companies I
know about personally).
See https://www.staticgen.com/ for a useful list of open source static
site generators.
DocBook and DITA have both been doing static site generation for years
(decades in the case of DocBook). I've done production work with
DocBook, DITA, and Middleman (a Ruby-based static site generator that
supports Markdown), though I'm not doing anything with doc tool chains
in my current role. While I really enjoyed writing xslts and appreciate
the power of semantic markup, I understand the popularity of generators
like Middleman, Jekyll, Sphinx, etc:
These static site generators support light-weight markup formats that
don't require (or all but require) an awesome commercial editor like
Oxygen to be productive. Github in turn supports these formats by
presenting a rendered view when you browse the repository and rendered
diffs in pull requests. Even without those features, the lighter weight
markup formats are easier to read in the line diff tool provided by your
favorite IDE. Editors are the site of holy wars and asking people to use
anything other than their one-true editor is often a non-starter.
These static site generators typically have support for web dev
convenience technologies like Sass (+ Bootstrap), CoffeeScript, and Haml
to make css and JavaScript bearable and free hipsters from the need to
write any angle brackets at all. There's nothing to stop you from using
Sass and CoffeeScript as part of an xslt-based generator, but having a
kit with all that built in, plus a little server runs locally and
auto-refreshes in your browser every time you save a file is a
convenient way to author.
The open source toolkits for DocBook and DITA offer base xslts for
generating html, but leave it to you to incorporate the other
convenience technologies.
Regards,
David
--
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--