OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-lightweight-dita message

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


Subject: RE: [dita-lightweight-dita] Specialization by example - tlotermtopic - basic structure


Hi Birgit,

Sorry I didn't include enough context. This example would be used to generate a specialization, so the outputclass is used to describe what specialized elements you want to create.

Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
mpriestl@ca.ibm.com
http://dita.xml.org/blog/michael-priestley



From:        "birgit" <birgit@xstructuring.eu>
To:        Michael Priestley/Toronto/IBM@IBMCA, <dita-lightweight-dita@lists.oasis-open.org>
Date:        09/02/2015 04:39 AM
Subject:        RE: [dita-lightweight-dita] Specialization by example - tlotermtopic - basic structure
Sent by:        <dita-lightweight-dita@lists.oasis-open.org>




Dear Michael,
Yes, you can do it this way but honestly I don’t like to put syntax information in @outputclass. That’s just the great thing of DITA that you can specialize new elements for special syntax/content. Yes, the use of @outputclass makes is flexible but also more suitable for errors.
Kind regards, Birgit
 
Van: dita-lightweight-dita@lists.oasis-open.org [mailto:dita-lightweight-dita@lists.oasis-open.org] Namens Michael Priestley
Verzonden:
dinsdag 25 augustus 2015 20:52
Aan:
dita-lightweight-dita@lists.oasis-open.org
Onderwerp:
[dita-lightweight-dita] Specialization by example - tlotermtopic - basic structure

 
Taking Don's example, and ignoring the metadata portions for now - just the basic section structures.

I wanted to capture:

- whether a content model is a sequence or a choice

       with a new attribute - collection-type - "borrowed" from map)

       if there is no collection-type, then it inherits the content model from its ancestor (including what elements are allowed - no need to define them all every time)

- which elements are required vs optional
       (defaults to required in a sequence, default to optional in a choice)

       using the importance attribute with restricted values

- when a title/label or other content is intended to be generated vs author-edited vs template-only (eg prompt text) or documentation

       with a new attribute contentrole with restricted values (editable, prompt, generate, doc)


Still to capture:

- metadata attribute specialization

- global/domain specializations of ph element, data element, props attribute

- constraints definition, including use of predefined constraints, or new constraints such as a global element removal, addition, or substitition

- show how conref could be used to assemble topic types and reuse domains from existing elements in other specification topics


<topic id="termdef_term" outputclass="termdeftopic"

       <title outputclass="tloterm">Structured Content</title>

       <body outputclass="tlotermbody" collection-type="sequence">

               <section outputclass="tlowhat">

                       <title contentrole="generate">What is it?</title>

                       <p>...</p></section>

               <section outputclass="tlowhy">

                       <title contentrole="generate">Why is it important?</title>

                       <p>...</p></section>

               <section outputclass="tloessay">

                       <title contentrole="generate">Why does a technical writer need to know this?</title>

                       <p>...</p></section>

               <section outputclass="tlosummary" collection-type="sequence">

                       <title contentrole="generate">Summary:</title>

                       <p>...</p></section>

       </body>

</topic>


In this example, all the sections have titles to be generated. All of them have content models that are inherited from <section>, so allow more than <p>, except for <tlosummary> that requires a single <p> element (I could also have expressed this by saying it was collection-type="choice" and making the <p> importance="required" explicitly).


Some things we could validate for:

       - if importance is set with a parent that doesn't have collection-type set

       - if outputclass is set with a parent that doesn't have outputclass set (unless it's also listed wherever/however we define domain specializations)


Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist

mpriestl@ca.ibm.com
http://dita.xml.org/blog/michael-priestley


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