RE: [dita] Enumerated Attributes to be Unenumerated

From
Erik Hennum <>
Date
2007-12-11T16:00:28+00:00
ID
Thread
RE: [dita] Enumerated Attributes to be Unenumerated
Hi, Jeff:

If the controlled values proposal is approved, we could provide standard enumerations of controlled values with a scheme map.

Erik Hennum



"Ogden, Jeff" <>

"Ogden, Jeff" <> 

12/11/2007 06:40 AM

To

"Eliot Kimber" <>, <>

cc

Subject

RE: [dita] Enumerated Attributes to be Unenumerated

If these attributes become unenumerated, would the suggested values

still be included in the DITA specification or would they just become

open ended?

Making the values unenumerated provides more flexibility for

specializers and users in general. Making the values unenumerated

provides less guidance to users and makes it easer to make mistakes that

may go undetected. Making the values unenumerated also put more burden

on specialization implementations when specializations are shared.

You can see that I've got mixed feelings about this proposal. I wonder

if we shouldn't unenumerate some attributes, but not others.  In any

case I think we should proceed cautiously.

   -Jeff

> -----Original Message-----

> From: Eliot Kimber [mailto:]

> Subject: [dita] Enumerated Attributes to be Unenumerated

> 

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

> 

> commonElements.mod:

> 

> - %display-atts;/@scale

> - %display-atts;/@expanse (for example, "spread" would be a useful

value

> here)

> - %select-atts;/@importance

> - %select-atts;/@status

> - %localization-atts;/@dir (for example, current list does not account

> for top-to-bottom languages)

> - note/@type

> - lq/@type

> - tm/@tmtype

> - param/@valuetype

> - draft-comment/@disposition

> 

> topic.mod

> 

> - %rel-atts;/@role

> 

> Issue: should @collection-type (%topicref-atts;, link-list, link-pool)

> be limited to the current values or be extensible? My initial thinking

> is that the list should be limited but if there are other reasonable

> values that people have identified as useful that would be an argument

> for allowing extension.

> 

> metaDecl.mod:

> 

> - author/@type

> - copyright/@type

> - permissions/@view

> - audience/@type

> - audience/@job

> - audience/@experiencelevel

> 

> xnalDomain.mod:

> 

> - authorinformation/@type

> 

> bookMap.mod:

> 

> - publishType/@value

> - bookrestriction/@value

>