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


Admittedly, working with DOCTYPES is a pain.

 

Typically with XSLT, you are trying to do something very specific for the desired output transform. I don't think abstracting and using parameters for this scenario buys you anything.

 

One solution is to validate with RelaxNG (the canonical DITA schema format), so you don't have to rely on a DOCTYPE at all.

 

If that is not an option, though, here is another XSLT approach that won't require changing the spec. You'll probably want to create some variable for the filenames based on the content you are processing (not included in this example):

 

   <xd:doc>
        <xd:desc>Define output formats</xd:desc>
    </xd:doc>
    <xsl:output indent="yes"/>
    <xsl:output name="map" doctype-public="-//OASIS//DTD DITA 1.3 Map//EN" doctype-system="map.dtd" indent="yes"/>
    <xsl:output name="topic" doctype-public="-//OASIS//DTD DITA 1.3 Topic//EN" doctype-system="topic.dtd" indent="yes"/>
    <xsl:output name="concept" doctype-public="-//OASIS//DTD DITA 1.3 Concept//EN" doctype-system="concept.dtd" indent="yes"/>
    <xsl:output name="task" doctype-public="-//OASIS//DTD DITA 1.3 Task//EN" doctype-system="task.dtd" indent="yes"/>
    <xsl:output name="reference" doctype-public="-//OASIS//DTD DITA 1.3 Reference//EN" doctype-system="reference.dtd" indent="yes"/>
    <xsl:output name="troubleshooting" doctype-public="-//OASIS//DTD DITA 1.3 Troubleshooting//EN" doctype-system="troubleshooting.dtd" indent="yes"/>
    <xsl:output name="glossentry" doctype-public="-//OASIS//DTD DITA 1.3 Glossary Entry//EN" doctype-system="glossentry.dtd" indent="yes"/>

 

<xsl:template match="map">

<xsl:result-document href="" format="map">

</xsl:template>

 

<xd:doc scope="component">
        <xd:desc>Generate generic topics</xd:desc>
    </xd:doc>
    <xsl:template match="topic" mode="topics">
        <xsl:call-template name="createTopic"/>
    </xsl:template>

 

<xd:doc scope="component">
        <xd:desc>Template for creation of topics</xd:desc>
    </xd:doc>

<xsl:template name="createTopic">
<xsl:result-document
            href="">             format="topic">

</xsl:template>

 

 

I'd prefer not to hardcode DOCTYPES into attributes, since DTDs aren't the only method for validating DITA documents. Especially if there are existing (though, painful) methods to process the XML.

 

Thanks and best regards,

 

--Scott

 

Voting member:

Boeing Data Standards Technical Advisory Board

OASIS DocBook TC (Secretary), Publishers SC (Chair)

OASIS DITA TC, Tech Comm SC, LwDITA SC, Learning Content SC (Secretary)

OASIS DITA Adoption TC

OASIS Augmented Reality in Information Products (ARIP) TC

 

Scott Hudson
Content Strategist, Digital Aviation Learning and Development

Jeppesen, A Boeing Company

55 Inverness Drive East

Englewood, CO  80112

303-328-6228 | Cell: 303-350-7934

 

 

This document contains only administrative, uncontrolled data under U.S. International Traffic in Arms Regulations.

 

 

From: <dita@lists.oasis-open.org> on behalf of Alan Houser <arh@groupwellesley.com>
Organization: Group Wellesley, Inc.
Reply-To: "arh@groupwellesley.com" <arh@groupwellesley.com>
Date: Friday, February 2, 2018 at 7:15 AM
To: Jang <jang@jang.nl>, OASIS DITA TC List <dita@lists.oasis-open.org>
Subject: Re: [dita] Question on Public IDs

 

Hi Jang,

Ahhh ... thank you. I had forgotten about this approach.

I'm still trying to get my head around the requirement to get the public ID (Arbitrary? A member of a pre-defined set?) and set it in a transformation result. I also look forward to hearing others' input.

-Alan

 

On 2/2/18 9:01 AM, Jang wrote:

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]