OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dita] Question on Public IDs


Hi Alan,

I have successfully parameterised the public ID by using <xsl:result-document> in my XSL and leaving the <xsl:output> empty.

<xsl:param name="pubtype"/>
<xsl:param name="systype"/>

<xsl:template match="/">
<xsl:result-document href=“newtopic.dita" doctype-public="{$pubtype}" doctype-system="{$systype}">
<xsl:apply-templates/>
</xsl:result-document>
</xsl:template>

But this would become much easier if the public ID of a document shell was copied into the value of an attribute on the root element. I now have to figure out the public ID and pass it to the main XSL as a parameter, which is a total hassle. There is a @domains from which the public ID could theoretically be derived but that is just another hassle. Replicating the public ID of a document shell in one of the attributes makes a lot of things much easier, I think. But I may be on a completely wrong track here - in which case I would like to hear from the XML gurus on the TC.

Jang F.M. Graat
Smart Information Design
Amsterdam, Netherlands
Cell: +31 646 854 996


On 2 Feb 2018, at 14:32, Alan Houser <arh@groupwellesley.com> wrote:

Hi Jang,

I'm glad you're looking at this sort of issue in FrameMaker ... I've long been frustrated with FrameMaker's XSLT support for other reasons, which we can go into if you're looking to improve FrameMaker's XSLT support in the general case.

I think even attempting this sort of processing (passing arbitrary public IDs to a result document) is problematic, particularly with XSLT. When I first attempted this in XSLT 1.0 (when it was not possible to do so), I learned from the XSLT cognoscenti that XSLT was not meant to be a general-purpose XML to XML transformation language. More recently, XSLT supports <xsl:output>, which allows one to set a public ID, but because <xsl:output> is a top-level stylesheet element, you cannot parameterize the public ID value in the result document.

IMO, "adding the public ID as an attribute value" is a losing proposition, at least with XSLT, because it's not possible to parameterize the XML declaration of the result document. Furthermore, using this value in the general case to adjust the transformation (via template parameterization or via other processing methods) strikes me as a scary proposition.

If I were a FrameMaker product developer, I might focus instead on implementing true (@class-aware) specialization support.  :-)  I acknowledge that this may be where you are trying to go.

-Alan


On 2/2/18 4:23 AM, Jang wrote:
Working on improved DITA support in FrameMaker prompts various questions about the reasons for some features present or absent in DITA. Here is one about public IDs.

For all kinds of processing it could be interesting to know which document type (public ID) was opened, but in many cases that information is stripped as it is not part of the XML content. One such case is processing the file with XSLT. If I need to pass the public ID to a result document, I need to pull it from the XML text file and pass it into the XSL as a parameter. This introduces an extra layer of non-XSL code which I would rather not implement.

Various document shells have the same root element (e.g. basetopic and topic, or task, machineryTask and generalTask), so having the root element is not enough to decide. There is the domains attribute, of course, but that is quite complex to handle and may even be different for the same topic type (task with or without certain optional domains included). Specialised topics may use the same root element as their specialisation base but need a different public ID to distinguish them from that base. 

Was there ever an idea of passing the public ID of a document type into an attribute of the root element? If yes, what were the reasons for not doing this and if no, would this be an interesting option for DITA 2.0 ?

Thanks

Jang F.M. Graat
Smart Information Design
Amsterdam, Netherlands
Cell: +31 646 854 996



-- 
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]