Re: [xsl] where to look for xsl folk..

Subject: Re: [xsl] where to look for xsl folk..
From: "adam adam@xxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 4 Jul 2016 00:02:09 -0000
in the systems i am building the entire lifecycle is kept in HTML, and
in some minor cases JATS

adam


On 07/03/2016 04:50 PM, Graydon graydon@xxxxxxxxx wrote:
> On Sun, Jul 03, 2016 at 09:16:38PM -0000, adam adam@xxxxxxxxxxxxxxx scripsit:
>> I think the model I have in mind for publishing might evade these
>> problems. Im not looking for a magic want, rather Im anticipating some
>> of the structure will necessarily have to be applied by the publisher.
>> It marks a very interesting case where publishers, when empowered with
>> the right tools, can bring back total control of the doc inhouse and
>> stop the ridiculous workflows that have publishers throwing docx files
>> over the wall to vendors who do all the file conversion manually (which
>> is both expensive, time consuming, and fails when there is a need to
>> update the published outout).
> That's a good model if you can get the authoring step to work on
> whatever the archival format is going to be.  (The archival format being
> the one that you retain, store, and regenerate the delivered content
> from as required, something XSLT is emphatically good for.  There are
> XML vocabularies specially designed to be the archival format.)
>
> If you're stuck with authoring in docx and repeated conversion,
> especially round-trip conversion (so producing the next delivered
> version means the current version has to be shoved back into docx for
> someone to work on the content) it's not so good.
>
> Some of the methodological search terms are "form-content separation"
> and "multi-channel publishing" and there are people hereabouts who know
> a lot about the subject.
>
> -- Graydon
> 

-- 

---
Adam Hyde
http://www.adamhyde.net/projects

Current Thread