Subject: Re: [xsl] XSLT or static site generator From: "Wendell Piez wapiez@xxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Mon, 2 May 2016 19:47:12 -0000 |
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: [xsl] 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_^
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT or static site gener, Eliot Kimber ekimber | Thread | [xsl] formatting not able to retain, Joga Singh Rawat jra |
Re: [xsl] XSLT or static site gener, Eliot Kimber ekimber | Date | Re: [xsl] BIDI problem in XSL-FO, Tony Graham tgraham@ |
Month |