dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] Enumerated Attributes to be Unenumerated
- From: Erik Hennum <ehennum@us.ibm.com>
- To: "Ogden, Jeff" <jogden@ptc.com>
- Date: Tue, 11 Dec 2007 07:57:42 -0800
Hi, Jeff:
If the controlled values proposal is approved, we could provide standard enumerations of controlled values with a scheme map.
Erik Hennum
ehennum@us.ibm.com
"Ogden, Jeff" <jogden@ptc.com>
"Ogden, Jeff" <jogden@ptc.com>
12/11/2007 06:40 AM
|
|
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:ekimber@reallysi.com]
> 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
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]