Re: enumerationDef support for element text() values

[Jim Tivy <jimt@bluestream.com>]

Hi Folks

Unfortunately missed the discussion on the 29th:
- Kris; Jim's question was why is enum for enumdev only for [see his email]
- Eliot; for one thing, if you allow that, you'd have to ensure that
your grammar limits the element to only text content, it couldn't
allow sub elements; that's the only reason I can think of.
- Chris; it also adds complexity to translation process.
- Nancy; in my recollection of the development, I think the
translation issue that was a big part of why it works this way.
- Dawn; can't you set it up with @translate='no'?
- Robert; this was supposed to be portable, that would make that much
more difficult. If you translated, you'd have to translate your
subjectscheme as well, or you'd have build errors.
- Chris; there are grammar-based solutions; you can create a domain
specialization of all your categories. It adjusts the complexity; as
it is now, you don't have to know how to edit grammar files. If it
were changed, that would be required to make it work.
- Kris; from point of view of complexity, I wouldn't support adding it
to DITA as a standard.
- Nancy; I agree, we don't want to make translation more complicated.
- Frank, not just complicated, impossible...
- Kris; any other comments;

Thanks for looking at this issue.  I could not attend as I have had a
meeting that conflicts with the TC lately.  I am seeing solution
architects choosing specializations with just attributes so they can
present the users with pick lists in tools like oxygen - in some cases
likely a bad practice.  In this case attributes are being used for
things that may need to be translated too.  This use of attributes of
course has always been true of the <data> tag as it uses a name value
pair - perhaps "data" has the connotation of not translatable.  But I
think this entire discussion implies more questions.  It would be
natural to assume in general that attributes are not seen by the
reader in the end rendition and element text() is seen by the end
reader.  It would be a false distinction in "semantic tagging" to
assume that values of text() could not be constrained to a set of
values but attribute values could be thus constrained.  The two
candidate mechanisms for constraining values are subjectSchemes and
keys. Subject scheme enumerationDefs with pick lists are a "copy"
mechanism whereas keyrefs are a reference mechanism.  And we know that
factored data modelling always moves toward reference mechanisms like
keyref.  Keyrefs also have less translation complexity as you would
translate the key map whereas in subject scheme you have to translate
both the scheme map and the "copies" of the values. A dita oriented
TMS might be able to do this easily - but it does add complexity.  So
perhaps the best "pick list" feature would be to connect a set of keys
to a certain element or path not a set of values as done with subject
scheme enumerationDef.  Hmm - would have to think more on this as this
discussion wades into the realm of factored data.

cheers
Jim

On Sat, Sep 12, 2020 at 9:56 AM Jim Tivy <jimt@bluestream.com> wrote:
>
> Hi Folks
>
> From time to time users of DITA will define elements where they wish to constrain the set of values possible to a "pick list".  This can be done today using enumerationdefs with subjectSchemes for attribute values but not for element text() values.  My question is, why was this enumertiondef mechanisms only implemented for attributes or attributes within an element and not element values as well.
>
> It would seem reasonable that the use of enumerationdef be extended to support element values.
>
> I could see use of this ranging from visible partNumbers to prolog change-item values to specialized element values.
>
>
> <change-item product="productA productB">
>       <change-person>Tom Cihak</change-person>
>       <change-organization>JEDEC</change-organization>
>       <change-completed>2013-03-23</change-completed>
>       <change-summary>Made change 1 to both products</change-summary>
>       <data>Details of change 1</data>
>     </change-item>
>
> Jim