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: otherprops



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]