Hi Ann,

As you are in the DITA-OT plugins you do have all the files available on the file system. So in XSL you should be able to open the file (as referenced in the href attribute of the xref element) and retrieve the title from that document.
Please have a look at the xsl function called 'document()'. See https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/ms256465(v=vs.100) as a possible reference.

So providing the correct path in the document() function will allow you to query for this information from the referenced file.

DITA-OT has other samples about this in the pre-process plugins as they replace the xref texts with the titles of the linked element as well.
So you can search and take inspiration from the OOTB DITA-OT plugins as well.
eg. the file topicpullImpl.xsl of the preprocess plugin it has samples on how the DITA-OT process is doing this.

Kind Regards,

Raf

Hi Raf,

Thanks for confirming that I was on the right path with my research into the topicpullImpl.xsl preprocessor file and the document() function.

What has me stumped is how I can read a file from the CMS given a GUID which is not part of a file system address. Do I need to do some type of conversion and add a file extension? 

Thanks again,

Ann

Hi Raf,

Thanks for confirming that I was on the right path with my research into the topicpullImpl.xsl preprocessor file and the document() function.

What has me stumped is how I can read a file from the CMS given a GUID which is not part of a file system address. Do I need to do some type of conversion and add a file extension? 

Thanks again,

Ann

Hi Ann,

Within the publishing process (the OOTB PUBLISH backgroundtask) the exported content in the temporary location of the related publishing job is filesystem based DITA. I mean with this that all the exported content has the GUID values of the href-attributes replaced by the respective filenames by which these objects are exported.

So I'm a bit puzzled why you want to go back into the CMS in order to read the title of the object.
You should just follow the route of the filename as provided in the href attribute of the xref.

So my main question would be whether or not you are looking for a solution during PUBLISHING or is this a question related to another functional area like exporting the workflow or translation report?

If you are in the PUBLISH process, then the href should have the filename and no longer the GUID as the value. If you still have the GUID then this means that the object is not part of your publication and the target file is no exported by the publish job.

If this is the case this xref statement should have been marked with the scope attribute equal to 'external'. In these scenario's the file will not be available on the filesystem and you could opt to first download (a version of) the referenced object and update the xref href-attribute with the corresponding filename before calling the DITA-OT.

So it depends a bit what type of xref you have.
If it is an external xref pointing to a DITA topic from another publication, you will need to do something.
if it is an internal xref the href attribute should already contain the correct filename.

I hope this helps,

Raf

Hi Raf,

Back again.

This challenge is rooted in requests from our customers who do not want to have to add files to the publication's Resources folder for every xref in their publication content as they heavily use xrefs to files not in the publication.

I presume the DITA transform is too late in the overall publishing process so can you advise where I can add customization to use the GUID provided in an xref to export the related file details so that they are available to me to pass to the DITA transform?

Thanks again,

Ann