OASIS Darwin Information Typing Architecture (DITA) TC

 View Only
  • 1.  enumerationDef support for element text() values

    Posted 09-12-2020 16:57



    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






  • 2.  Re: [dita] enumerationDef support for element text() values

    Posted 09-15-2020 14:08




    All,
    I can say that this is one of the most asked questions I field from my customers as well, especially as it relates to metadata such as <category>. We sometimes might use a metadata_keys file to specify those values. So the key file is
    a giant prolog, with all the possible metadata element values and it is placed in all map templates. Then the topics or maps can reference those keys for the appropriate values, which can be similar to a pick list in some tools where you see the list of keys
    in the key file. I suppose you could enumerate the conkeyref, but that seems dangerous if you are using keys for other purposes. 

     
    Dawn
     

    From: dita <dita@lists.oasis-open.org> on behalf of Jim Tivy <jimt@bluestream.com>
    Date: Saturday, September 12, 2020 at 10:57 AM
    To: dita <dita@lists.oasis-open.org>
    Subject: [dita] enumerationDef support for element text() values


     

    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






  • 3.  Re: enumerationDef support for element text() values

    Posted 10-18-2020 17:39
    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