dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: otherprops
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: hedley.finger@myob.com
- Date: Mon, 14 Mar 2005 20:07:44 -0500
Thanks for the comment - we know this
is a weak point in the current version of DITA, and there is a documented
workaround in the architectural specification: see the topic "Limits
of specialization", in the specialization chapter.
I know attribute specialization is one
of the features we are hoping to incorporate in future versions of DITA.
In the meantime, the workaround (adding the attributes in a customization
layer, and feeding them into otherprops during preprocessing) should allow
you to achieve pretty much the same functionality you are looking for below.
IE, you will have the metadata attributes you need, and you will still
be publishing through a valid DITA intermediate stage.
When attribute specialization does become
available, you should be able to upgrade your customization layer to a
specialization module, and simply remove the preprocessing step.
Michael Priestley
mpriestl@ca.ibm.com
comment-form@oasis-open.org
03/14/2005 07:51 PM
Please respond to
hedley.finger |
|
To
| dita-comment@lists.oasis-open.org
|
cc
|
|
Subject
| [dita-comment] Public Comment |
|
Comment from: hedley.finger@myob.com
I am not an XML or DITA expert. We use conditions extensively in
FrameMaker (FM) and have implemented our own FrameScript workaround so
that FM conditions will AND as well as OR (the only natively supported
behaviour). We want to migrate our unstructured FM files to XML.
We are looking at Arbortext Epic and like the way conditions ("profiles")
are implemented as multi-valued attributes, e.g. <span condPlat="Linux_RH;Linux_Mdk;Linus_Suse"
condMkt="us;au;uk;nz">. In that model, values within
a single condition attribute OR, e.g. if Linux_RH is true and us is true,
then <span> is revealed. But different condition attributes
AND, e.g. if us, au, uk, and nz are all false, then whatever the truth
evaluation of condPlat, <span> is concealed.
My concern with the DITA %select-atts; model is that only the attributes
platform and audience are direct equivalents to the conditions we currently
use. The other eight or so will all have to be shovelled into otherprops
in an ugly and writer unfriendly manner incompatible with Arbortext Epic
or any other attrib-based conditioning scheme.
What would be nice is for some way to be able to specialize otherprops
or some method of supporting arbitrary numbers of conditional attributes.
Interchangeability with other processors is probably meaningless
unless those processors could have some data-driven way of interpreting
specializations of otherprops or the alternative mechanisms for supporting
unlimited conditional attributes.
In fact, considering the needs of future external processors, you might
consider a general solution that would allow a processor to understand
arbitrary conditional attributes, perhaps with some standardized XML structure
to describe conditions and the truth values of the attribute values, e.g.
"us;au;uk;nz". Then otherprops would simply be a reference
to this standard XML structure, perhaps as an external file available to
applications, e.g. help browsers, accounting programs, log-on routines,
etc.
We wish to develop modular help for a modular product. Users would
also have role profiles/access profiles assigned. So the help engine
needs to read the truth value from somewhere and then edit the XML content
on the fly to reveal/conceal content appropriately.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]