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: [dita] otherprops syntax - should we specify?



This is an excellent discussion, and I think the onus is now on me to provide some background on why we've taken the approach we have, since it does differ from what we've all seen in other architectures. This difference is in fact not an oversight, but is based on extensive experience with full boolean logic conditionality, and is designed to be an improvement on traditional conditional processing architectures.

There are two factors that make DITA's approach a bit different from traditional architectures:

1) Maps. Singlesourcing in DITA is primarily accomplished by using different maps; each map can include a mix of shared and unique topics without requiring communication or coordination between the reusers.

Because maps provide the main mechanism for reuse and singlesourcing, conditionality is only required within relatively contained and limited contexts, like a single topic. If the conditionality gets too complicated to maintain easily, the problem topic can be refactored into two or more separate topics that share common elements through conref, instead of having a single topic with complex metadata. This is covered in detail in briefing 5 of the DITA deepdive series.

2) Semantic groupings of values into separate attributes, so you have multiple axes of metadata rather than an undifferentiated list of values. This semantic grouping allows implicit boolean logic to be applied at build time, following the rules laid out in the spec (ie all the values in one attribute must be excluded for the element to be excluded).

The existing attributes are not a complete set of metadata axes, however; hence the need to provide semantic groupings within the one attribute that does not have a specific semantic already associated with it (otherprops).

There are several advantages of semantic groupings over boolean logic:

1) they can be easily understood by new writers (eg when a document's ownership is transferred or shared).
2) as a result, they can accomodate longer lists of values (ie heavier reuse) without becoming unmaintainable.
3) because they are simple metadata assertions, they can be used for more than just filtering (eg flagging and search).

Adding boolean logic support would compromise all of these benefits. There is a cost associated with maintaining complex logic that can drastically undermine the cost efficiencies of singlesourcing. I've seen many projects hit this wall with traditional approaches, which is why we took a different approach, supporting coordinated strategies based on conref, maps, and metadata rather than using condition lists with boolean logic.

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".

Thanks for the discussion, I hope this background is useful.

Michael Priestley
mpriestl@ca.ibm.com




"Rob Frankland" <robf@rascalsoftware.com>

01/10/2005 06:08 PM

To
"'W. Eliot Kimber'" <ekimber@innodata-isogen.com>, "'Christopher Wong'" <cwong@idiominc.com>
cc
"'DITA TC list'" <dita@lists.oasis-open.org>
Subject
RE: [dita] otherprops syntax - should we specify?





I'll add my two cents worth here, although I have not coded anything using
DITA. Users want conditional that are both easy to use and powerful. I
cannot tell from the discussion if DITA conditionals support any type of
Boolean logic but they will need to in version 2.0, if not now. At the
simplest, users want to define three conditions and be able to make a
selection of two which seems possible currently. However, making a condition
based on a NOT does not seem to be accommodated. If I am way off base, I
apologize in advance.

Rob

-----Original Message-----
From: W. Eliot Kimber [mailto:ekimber@innodata-isogen.com]
Sent: Monday, January 10, 2005 1:56 PM
To: Christopher Wong
Cc: DITA TC list
Subject: Re: [dita] otherprops syntax - should we specify?

Christopher Wong wrote:

> Does anyone else know what other people do with otherprops?

I would think that any non-trivial use of DITA that needs to account for
business-specific conditionality would quickly find the DITA-supplied
conditions insufficient. Therefore I would assume that almost *any* use
of DITA that needed conditionality would require additional condition
types and valuds.

This would certainly be the case for any client I'm likely to have that
wanted to implement a DITA-based XML application.

Cheers,

E.
--
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]