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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-comment message

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


Subject: 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]