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