XML restructuring: XSLT vs. Scripting?

[tobias.wantzen]

Hi there,

I’d like to know your pros and cons about:

How to restructure XML files to fit InDesign template’s needs? Is it better to use XSLT while importing or to restructure using scripting after XML import in InDesign?

Thanks for sharing your opinions

Tobias

[BSKTCreation]

Hi Tobias,

I've been working with XML restructuring in InDesign with JavaScript for a few years (I'm no expert though). Here is my 2 cents...

Pro's

- no template needed, I have gone away from templates but you can restructure to use them (I used to do this)

- once I understood how it's done it was quite easy (these guys on the forum helped me heaps)

- now I push all my data into JSON for easy access, I find this better than restructuring the XML

- you have full control of your data (no communicating with an external developer like I needed to when it was handled in XSLT)

Con's

- a non-InDesign developer might not want to touch an InDesign script (so you might be putting your work into a niche spot)

- if you do it the wrong way it can take ages to run (damn those nested loops)

- a lot less documentation on the process (but the forum guys can help with that)

Just my experience.

Brett

[tobias.wantzen]

Brett, thank you for kindly sharing your thoughts!

Just for clarification: You’re not using any kind of template document? So you build every document instance from zero via scripting?

And you’re not using the XML capabilities of InDesign, but rather read the XML file into a JSON and then build the document?

If I might ask another question: How do you handle your generated InDesign documents, when you get an updated XML file? How do you update the contents inside the InDesign document?

In my experience InDesign is a nice tool for building documents form XML source, but when it comes to updates it gets horrible - or have I missed some useful magic to work on this topic? ...

Thanks in advance

Tobias

[BSKTCreation]

Sure Tobias I now build everything from JavaScript in InDesign, no templates, and no XML auto population.

I used to have:

- a template

- an XML file that was formatted via XSLT that would auto populate InDesign during import; and

- a script to tie them together and massage the product

This worked fantastically if all the stars aligned, but it was a nightmare to maintain when changes were requested as the templates had 1,000's of referenced textFrames and a complex XML structure that was repeated over 100's of pages (I didn't know any better at the time and dug myself quite a hole). It became apparent that I needed a solution that could use our default XML structure (defined by the database) and  be flexible to adhoc changes to design and content. A template in my situation wasn't conducive to variations to the original layout or content (but they might have been poorly designed, I'm not sure).

The solution I cam up with was to remove templates from the equation completely so I now only had:

- a generic XML structure; and

- a mega script that did everything

This was still far too complex and hard to maintain, so I significantly simplified the process by separating the scripts into a generic function library and a macro script for the product that I am creating (this got rid of all my code duplication and reduced the size of my scripts by over 50%).

So now my set-up looks like this:

- a generic XML structure that is exported native from our database

- a generic function library (99% of all functions are put in here, and they've been designed with the single use principle); and

- a macro script that builds the product (this is what I run, and I've written it close to English so a non-programmer can read and understand)

Also, because I'm not using a template I only need to import assets on an "as-needs" basis, where-as the template had all assets pre-populated  inside it (30+ mb templates were common). This gave my scripts a massive time boost and it allowed me to design products based on algorithms rather than a manual positioning inside a template. This meant that I could change the design of a product on the fly without breaking it because I designed it to be dynamic in nature.

I must emphasise that this process has taken me many years to develop through trial and error and it might not suit your work situation.

I hope this gives you a clearer picture of what I was saying before.

Brett

[Stefan Rakete]

Hi Tobias, this is a very good question. Here is my remarks:

Use XSL to...

... filter out XML data that is not needed in the indesign document

... create the structure you need before placing the xmlElement on the page

InDesign does not support grouping in the XSL, so this needs to be done with the JavaScript in the XML structure after importing.

Thanks Stefan

[Loic.Aigon]

I do myself like to merge both of them. I think XML tagging convenient to spot elements onto the pages. And I can take advantage of XLST when needed. However I never use XML Import exclusively nor I would like to do 100% scripting for setting layouts.

Besides, I am working on a xml workflow for a magazines company and the inherited xml from the CMS can have nodes with child nodes intended for styling purposes (ex. bold).

Importing this content through JS (.contents="xxx") wouldn't take those styles into accounts nor any kind of styles relationship xml engine allows (map tags to styles). But I use xml import through scripting so I can easily spot the parent node I am interested in and import xml content from this place.

In short, I let InDesign work for me when it can and only do the job myself if I think the results will be better or smoother

FWIW

Loic