RE: [dita] Specialization of Attributes

["Esrig, Bruce (Bruce)" <esrig@lucent.com>]

Hi Erik,

 

I can take one slice through, but it leaves some open questions. And I may be taking an approach that is on a completely different track compared with what you are proposing.

 

I agree that there are two different kinds of specialization, but I'd characterize them differently, and not yet look at enumerated types. One is scoping (structural refinement of values) ("has-a", or "is-a") and the other is type refinement ("is-a-kind-of").

 

There are a variety of mechanisms at play that we're trying to coordinate and harmonize.

 

1. Subject hierarchy:

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

 

2. Type specialization of attributes:

 

machine="intel"

operatingSystem="windows"

 

where machine and operatingSystem are specializations of platform.

 

This permits us to generalize as follows.

 

platform="machine(intel)" AND platform="operatingSystem(windows)"

 

Unfortunately, this points out a difficulty with our AND/OR strategy. We can't express an AND that involves two values for the same attribute, and in this example we need to do that in order to represent the desired expression.

 

For that reason, I'm seeing a need for logical expressions within attribute values.

 

3. Returning to types of specialization, we should also look at cases that require scoped values, but that might require a different example (at the least for expository purposes).

 

Best wishes,

 

Bruce

 

 

===========

 

Aside on enumerated types:

 

Enumerated types are a great thing, but my assumption has been that any enumeration would be external to the DITA language. We might intend a type to be enumerated, but we would not actually declare its values. In the DITA type system, a type is assumed to be extensible simply by using a new value in the type (extension of values) or declaring a new specialization of a parent type (extension of types).

-----Original Message-----
From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Wednesday, April 19, 2006 1:50 PM
To: dita@lists.oasis-open.org
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

• Create a new selection attribute for a specialized enumeration.
• Create a new enumerated value for a specialized controlled value.

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:

• Specialized enumerations with the attribute name syntax
• Specialized values with scoped values

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