Re: XSLT or static site generator

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@xxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx
> Sent:May 2, 2016 9:17 AM
> To:xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Reply-to:xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject:Re:  XSLT or static site generator
>
> On 5/2/16 9:22 AM, Eliot Kimber ekimber@xxxxxxxxxxxx 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_^