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