Re: [dita] Enumerated Attributes to be Unenumerated

[Eliot Kimber <ekimber@reallysi.com>]

Eliot Kimber wrote:
> The following attributes have enumerated values in DITA 1.1 and should 
> probably have unconstrained values in DITA 1.2. I have listed 
> @collection-type as an open issue as I can see solid arguments both for 
> using the current values and for allowing new values.

Michael Priestly, Jeff Ogden, Robert Anderson, and myself met to discuss 
the unenumeration proposal. We came to consensus on the final design 
outlined below. I am posting this now so that the decision can be 
considered for Tuesday's meeting. I will post a formal proposal before 
the end of the day Friday.

Of the original list of attributes to potentially be unenumerated, we 
determined that only the following should be unenumerated, with the 
current values listed as either examples or values that must be 
recognized by processors (depending on the nature of the values, which 
should be clear from the current spec):

   - draft-comment/@disposition
   - author/@type
   - authorinformation/@type (is a specialization of author)
   - copyright/@type
   - permissions/@view
   - audience/@type, @job, @experiencelevel
   - publishtype/@value
   - bookrestriction/@value

These are attributes on which there are no particular processing 
dependencies (that is, no known processors that strongly depend on 
specific values) and for which the current set of values is clearly 
insufficient.

All other enumerated attributes will continue to be enumerated for 1.2. 
However, we identified two places where the current lists should be 
extended:

- Add "spread" to the @expanse attribute. The value "spread" indicates 
that, if possible, the object should be rendered across a multi-page 
spread (normally a two-page spreads but some book designs may provide 
for more pages in a spread, such as foldouts). If the rendition target 
does not have anything corresponding to spreads then spread has the same 
meaning as "page".

[I have current clients that have this requirement and it's a rendering 
option that could be implemented by existing non-XSL-FO-based XML-aware 
composition tools (e.g., InDesign, XPP, 3B2, etc.).]

- Add additional values to the note/@type attribute as identified by the 
Machine Industry Subcommittee.

Once there is general tool support for some form of extensible 
controlled value mechanism we can fully unenumerate the remaining 
attributes.

We discussed the possibility of allowing local configuration of these 
attributes by providing a parameter entity that would allow local shells 
to change unenumerated attributes from being unconstrained to specifying 
fixed lists of values. However, Michael pointed out that this could 
potentially cause conrefs to result in invalid results per the current 
constraints imposed by the conref facility, so we rejected this idea 
since it would require revising the conref rules, which we did not want 
to even suggest for 1.2.

Cheers,

Eliot

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com