Using DITA variables in XSLT Scenario

[Dirk.Becker]

When I edit DITA files in my XML Editor 16.1, I sometimes run an XSLT on the current document.
While this XSLT might later end up in a customized DITA OT, I currently just launch it via a project specific XSLT scenario.

Unfortunately I have not yet found a way to refer to DITA settings from within the XSLT. Ideally I'd have them mapped into the Editor Values that are available within XSLT Scenario parameters. These values would be:
- current DITA root map, from the maps manager
- name of the current profiling condition set
- eventually actual conditions such as the effective audience
- even better would be if a function could resolve a conkeyref within the scope of the XSLT input document

Is anything of above already available and I just missed the matching manual page? The Editor Values page referenced by the XSLT param editor only gives generic functions such as file name, path and so forth.

Thanks,
Dirk

[Radu]

Hi Dirk,

Please see some answers below:

While this XSLT might later end up in a customized DITA OT, I currently just launch it via a project specific XSLT scenario.

Looking below, indeed your XSLT at least looks like a possible DITA Open Toolkit plugin because it would have access to some of the stuff you mention below.
Also I do not quite understand what the XSLT does, maybe if I did I could have other ideas for you.

Unfortunately I have not yet found a way to refer to DITA settings from within the XSLT. Ideally I'd have them mapped into the Editor Values that are available within XSLT Scenario parameters. These values would be:
- current DITA root map, from the maps manager

We have some plans to make such an editor variable available, I will add your vote for this.

- name of the current profiling condition set

We also have some plans to make such an editor variable available, I will add your vote for this.

- eventually actual conditions such as the effective audience

Your profiling condition sets refer to DITAVAL filter files, right? Your XSLT could also read the DITAVAL filter file and interpret its exclusion rules.

Code: Select all

- even better would be if a function could resolve a conkeyref within the scope of the XSLT input document

Mapping a conkeyref is quite difficult because you need to know the root map and you also need to parse all the submaps referenced directly or indirectly in the root map in order to create the key space (the mapping between keys and resources). Oxygen has this key space available in our internal code and we use it in many places, for example for rendering an opened topic which has a conkeyref but we do not have this internal information exposed.

Is anything of above already available and I just missed the matching manual page? The Editor Values page referenced by the XSLT param editor only gives generic functions such as file name, path and so forth.

Mostly all editor variables listed here should also work in XSLT stylesheet params although the list of editor variables presented to you when editing the parameter might indeed be smaller (because there are very many editor variables):

https://www.oxygenxml.com/doc/versions/ ... ables.html

Regards,
Radu

[Dirk.Becker]

Thanks for the long reply.

The use case is this:

I'm developing connectivity software (InDesign plugins) for a third party system (DAM/CMS) which has less than stellar documentation (a reluctantly maintained wiki), but at least an Atom/AtomPub API exposing many internal objects.

Since I have turned to DITA for all my external and internal documentation, I also write write my notes regarding that external system in the same format. For the various object kinds I use an XSLT to produce a starting point DITA document from an AtomPub query, that I then manually edit with whatever notes come to mind, add completely manual sections and so forth.

Arrives the next generation of the external system. I re-generate the same documents, with my manual edits from the previous generation merged in by the XSLT. In File-Diff I open that new generation from its temp folder side by side with its previous version and manually handle the differences - for both the notes, for my matching code, or the XSLT might have screwed up. The XSLT also validates the available data against inconsistencies that are missed by the external system, it produces string tables for my own localization mechanisms again based on DITA, and many other things that I want to manually handle further downstream.

Next step: point the same XSLT and documentation worksheets towards a client's production site. The live documentation turns into a consistency report, finds me constellations that I missed in my test environment, picks up client specific localization terms and so forth. Here comes my need for passing actual DITA values - many customer specific settings already exist as DITA elements utilizing all those DITA indirections as needed for customized documentation. Thus I'd love to pass the fully resolved DITA conkeyref - the same value that Oxygen Editor will display considering root map, active map, applied condition set and so forth. For obvious reasons I'd prefer a simple editor value/function over something that I'd have to distill out of a previous DITA OT run (far too infrequent) or even having to reimplement an OT subset within my own XSLT.

Dirk

[Dirk.Becker]

Your profiling condition sets refer to DITAVAL filter files, right? Your XSLT could also read the DITAVAL filter file and interpret its exclusion rules.

Actually I found the non-DITAVAL condition sets more convenient and currently use those. This might change in the long run, but even then why should my XSLT need to reinvent the wheel when the effective values could be injected as parameters.

[sorin_carbunaru]

Hello there,

I wanted to announce that oXygen 19.1 is now available. In this version we added 4 new editor variables related to the DITA root map:

• - ${rootMapFile}- Editor variable which will be expanded to the current root map file path.
  - ${rootMapDir} - Editor variable which will be expanded to the current root map parent directory file path.
  - ${rootMapURL} - Editor variable which will be expanded to the current root map URL.
  - ${rootMapDirURL} - Editor variable which will be expanded to the current root map parent directory URL.

All the best wishes,
Sorin Carbunaru
oXygen XML