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

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>
                <section outputclass="tlowhy">
                        <title contentrole="generate">Why is it important?</title>
                <section outputclass="tloessay">
                        <title contentrole="generate">Why does a technical writer need to know this?</title>
                <section outputclass="tlosummary" collection-type="sequence">
                        <title contentrole="generate">Summary:</title>

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

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