MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] otherprops syntax - should we specify?
Michael Priestley wrote:
> A specific note about NOT values:
> - a NOT value cannot be easily used for anything except filtering (eg hard
> to flag).
> - a NOT value can be rendered invalid when new platforms/products are
> added (does the paragraph still apply to every platform except Linux once
> you add other flavours of Unix?)
> - if a NOT value absolutely must be used, it can be handled without
> explicit boolean support by creating a new unitary value; eg instead of
> "NOT Linux" use "NOTLinux".
Based on my practical experience with conditionality (what I normally
call "applicability" because it defines to which conditions an element
applies to), I agree with Michael's overall analysis, particularly that
a complete boolean expression language is too much overhead for most
applications.
I also agree generally with the statement that in a map-based re-use
environment you *can* reduce some of the conditionality complexity by
having different maps. However, in discussing these issues with one of
my clients, who has both complex re-use requirements and complex
conditionality requirements and many different authoring groups, it
became clear that some groups would accept having different maps for
different sets of conditions and some would not. Some of this stems from
existing practice and work habits, some of it stems from limitations
imposed by different tools, some of it stems from practicalities of
various business processes, such as localization workflows. So even
though Michael is correct, you are not likely to get universal
acceptance of the approach.
For the latest application I've built for a client, we were able to
satisfy the applicability requirements by using lists of single tokens
that represented either positive statements, e.g.,
presentation_target="html print" or negative statements, e.g.,
presentation_target="not-help". A list of tokens is an implied logical
OR if all the statements are positive. That is, an element is applicable
if *any* of the conditions apply. An element is not applicable if and
only if none of the conditions apply. Negative conditions can be
interpreted as implying a list of positive conditions reflecting the
inverse of the negative statement.
The biggest challenge was in the implementation, where we found we had
to use procedural logic to correctly interpret some combinations of
positive and negative values, but it was never a problem for authors
(that is, we couldn't implement it in XSLT with just simple value
matches--I found it easier to put this logic in Java).
The biggest issue I've run into is in using distinct attributes for
different axes of conditionality. The problem of course is that as new
axes are discovered you must update the DTDs to add attributes for the
axes. If you are defining the attributes as enumerated values you have
to update the DTDs whenever the list of values changes. If you know that
the axes are dynamic or likely to change in the future you start to
think that it might be better to have a single "applicability" attribute
and use condition names to distinguish the axes. As the axes tend to
reflect local business processes, business objects, and practice, it is
almost a certainty that they will change over time.
I think this is the case in DITA as an interchange standard since it's
impossible for DITA to anticipate all the possible axes of its users, so
either you need a way to declare new axis attributes (pre my earlier
email) or you use one attribute and put the axes in the condition names).
If we say that condition names are namespace-qualified names, then you
have the opportunity to formally bind an axis to a namespace, providing
some hope of binding the axis to a formal definition of the semantics of
that axis. It also reflects that a given axis is in fact a space of
names, that is, names of conditions. For example, I might do something like:
<mytopic
xmlns:rend_targ="http://www.example.com/ns/condition_axes/rendition_target";
xmlns:market_region="http://www.example.com/ns/condition_axes/marketing_region";>
...
<mytopicbody>
<p applicability="rend_targ:print rend_targ:html
market_region:amea">For AMEA only</p>
<p applicability="rend_targ:print rend_targ:html
market_region:northamerica">For North America only</p>
...
</mytopicbody>
</mytopic>
In use cases where the conditionality requirements demand full boolean
logic, the approach I tend to take is to add indirection by creating
"condition definitions" where each condition definition has a unique
name within some scope (either within its axis or across all conditions,
whatever is most appropriate). This provides users with a simple list of
applicability keywords and centralizes the complexity to a separate
location where it can be managed by specialists.
This also gives you a place to define "effectivity messages".
Effectivity is orthoganal to applicability in that you only need an
effectivity statement if a given rendition includes information for two
different conditions within the same axis. For example, if I have the
axis "engineering change" and I can publish versions of the document
that reflect a single engineering change being appliable or that reflect
multiple engineer changes, in the first case I don't need effectivity
statements because there's no ambiguity, in the second case I do. Thus
whether or not you put out an effectivity statement is a function of the
rendition conditions, not the core information.
The source might look like this:
<procedure>
...
<step_alts>
<step applicability="ec_10-c">Attach nut p/n 23456 to bolt p/n
56437. Tighten to 32nm.</step>
<step applicability="ec_12-d">Attach nut p/n 76543 to bolt p/n
56437. Tighten to 26nm.</step>
</step_alts>
...
</procedure>
That is, in the first case, my rendition might look like this:
Step 2. Attach nut p/n 23456 to bolt p/n 56437. Tighten to 32nm.
In the second case, my rendition might look like this:
For E/C 10-c:
Step 2. Attach nut p/n 23456 to bolt p/n 56437. Tighten to 32nm.
For E/C 12-d:
Step 2. Attach nut p/n 76543 to bolt p/n 56437. Tighten to 26nm.
The DITA standard, as far as I can tell, makes no explicit provision for
effectivity. I don't know that it needs to because effectivity issues
can be pushed out to the "condition specification". For example, to
satisfy the above example, I might have condition definitions like this:
<condition_defs>
<condition name="ec_10-c">
<true_when>EC_10-c</true_when>
<effectivity_statement>For E/C 10-c</effectivity_statement>
</condition>
<condition name="ec_12-d">
<true_when>EC_12-d</true_when>
<effectivity_statement>For E/C 12-d</effectivity_statement>
</condition>
</condition_defs>
This condition definition mechanism can be completely outside the DITA
parts of the application since it is only applied during authoring or
rendition and doesn't affect the base document syntax at all.
I've seen this requirement most in aircraft maintenance information
where the conditions might be "if AA AND EC 123 applied AND operating
environment is "desert" AND operation hours > 1000". This type of
condition usually reflects some business object or condition that really
needs to be defined as a distinct thing. Thus, even though it could, in
theory have been expressed as a sequence of simple conditions, it better
fits the business process to objectify it in this way. In addition, the
processing of the conditions can then be as simple or sophisticated as
required without changing the authoring interface or the core document
markup.
Note that this indirect approach can always be retrofitted to the simple
keyword approach, so it could be applied to a DITA document unilaterally
if needed. That is, there's no need for DITA to step up to this level of
complexity unless we decided it was a common requirement, which it
probably isn't.
Cheers,
Eliot
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122
ekimber@innodata-isogen.com
www.innodata-isogen.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]