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] Specialization of Attributes


Hi, Esteemed TC:

One more time with indentation (pretty important in this case for clarity). Apologies for the redundancy.

--------------------------------------------------------------------------------------------------

Just to check agreement -- a selection attribute provides an enumeration of controlled values. In specializing a selection attribute, we are defining either a subset of the enumeration or defining a new value whose semantic is a subset of an existing value.

As we've discussed before, one example would be a specialization of the platform enumeration:

platform
....machine
........intel
........macintosh
....operatingSystem
........linux
........windows

Here, we're dividing an existing enumeration into two separate enumerations. That is, macintosh and intel are not operating systems nor are linux and windows machines. All are still distinct platform values, but a more specific enumeration can also be specified.

By contrast, here's a specialization of the programmer and user values:

audience
....programmer
........applicationDeveloper
........systemArchitect
....user
........decisionMaker
........technicalSupport

In the audience case, we still have one enumeration. A systemArchitect and a decisionMaker are distinct roles within a single enumeration of potential audience roles. We're just saying that applicationDeveloper is a special kind of programmer.

The two different types of specialization have different treatment in the conditional logic. The exclusion logic should AND-relate values within an enumeration and OR-relate values from different enumerations. For example, the conditional logic would be to exclude ((intel OR macintosh) AND windows AND (applicationDeveloper OR decisionMaker)).

To turn those abstractions into XML, we need to


To fullfill the DITA promise, we also need to be able to revert from the special understanding to a more general, shared understanding by turning the specialized enumeration to the base enumeration and turning a specialized value into its base value.

To get a complete equivalent for multiple specialized enumerations in a base enumeration, we'd have to generate a value for each permutation of the values from different subordinate enumerations. In the example:

platform
....intelWithAnyOS
....intelWithLinux
....intelWithWindows
....linuxOnAnyMachine
....macintoshWithAnyOS
....macintoshWithLinux
....macintoshWithWindows
....windowsOnAnyMachine

Either that or simplify the values as part of reverting to a general understanding.

With that as background, how do we handle these extensions in a way that meets the DITA goals of both sound architecture and pragmatic use? I understand the issue 20 proposal (http://www.oasis-open.org/apps/org/workgroup/dita/download.php/17329/IssueNumber20.html) as addressing:


Hoping that's useful,


Erik Hennum
ehennum@us.ibm.com


PS. FWIW, the DITA conditional logic is essentially the same as facet taxonomy logic, just excluding instead of including (a penny that dropped during Su-Laine's excellent presentation on DITA conditional logic).

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