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

Inactive hide details for "Ogden, Jeff" <jogden@ptc.com>"Ogden, Jeff" <jogden@ptc.com>

          "Ogden, Jeff" <jogden@ptc.com>

          12/11/2007 06:40 AM


"Eliot Kimber" <ekimber@reallysi.com>, <dita@lists.oasis-open.org>



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.


> -----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
> using the current values and for allowing new values.
> commonElements.mod:
> - %display-atts;/@scale
> - %display-atts;/@expanse (for example, "spread" would be a useful
> 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

GIF image

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