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: Fwd: [dita-comment] 1.3 troubleshooting topic permits empty remedy element?


Hi,

Last month, I had a dialog with George Bina about DITA topic ( ' topic/topic ') showing up in the content model when task was a nested topic within troubleshooting. I verified that this was the case and traced its cause to the fact that I had not overridden the task-info-types parameter entity in troubleshooting.dtd. Consequently, the model for task in task.mod reverted to its default value for task-info-types, which is topic. The solution is to add task-info-types to the troubleshooting topic's shell and set its value to "no-topic-nesting".

I thought that we had discussed this with the TC last month, but I can find no evidence that we did. Please add this item to the TC agenda so that we can get model corrected. It's "what I know that just ain't so" that causes most of my problems.

Best Regards,
Bob Thomas


---------- Forwarded message ----------
From: George Bina <george@oxygenxml.com>
Date: Thu, Apr 2, 2015 at 1:59 AM
Subject: Re: [dita-comment] 1.3 troubleshooting topic permits empty remedy element?
To: Bob Thomas <bob.thomas@tagsmiths.com>
Cc: dita-comment <dita-comment@lists.oasis-open.org>


Thanks Bob,

We updated the DTD as you suggested.

Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

On 02/04/15 06:24, Bob Thomas wrote:
Hi George,

I took a deeper look at this, and I discovered an implementation error
in troubleshooting.dtd. Specifically, the following parameter entity
must be added to the "TOPIC NESTING OVERRIDE" section of
troubleshooting.dtd:

<!ENTITY % task-info-types
               "no-topic-nesting"
 >

Without that override being present, the %task-info-types; parameter
entity defaults to its definition in topic.mod, which is %info-types;.
The %info-types; parameter entity is set to "topic" in topic.mod. That
is why we are seeing topic at the end of an embedded task in
troubleshooting.

Best Regards,
Bob

On Wed, Apr 1, 2015 at 8:10 AM, George Bina <george@oxygenxml.com
<mailto:george@oxygenxml.com>> wrote:

    Thanks Bob,

    The problem is that the inner task allows further an inner topic
    rather than task (the other information types allow embedding the
    same type further, any other task allows embedding a task not a topic).

    Best Regards,
    George
    --
    George Cristian Bina
    <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
    http://www.oxygenxml.com

    On 01/04/15 16:59, Bob Thomas wrote:

        Hi Joe,

        Initially the remedy model required exactly one steps,
        steps-unordered,
        or steps-informal element. An unfortunate side-effect of that
        requirement was that remedy could not use conref content without
        having
        a non-functioning child steps* element, which requires a step
        element,
        which requires a cmd element (steps-informal would reduce this
        chain,
        but how many people would think to try it?). We decided to allow
        empty
        remedy to eliminate required children for conref. This is also
        why title
        is optional for condition and context.

        Hi George,

        There were use cases where people wanted to embed an entire task
        topic
        within troubleshooting instead of using remedy. The rationale
        was that
        the prerequisites had to accompany the steps. This is definitely an
        edge, or corner case.

        Best Regards,
        Bob Thomas

        On Wed, Apr 1, 2015 at 2:55 AM, Joe Pairman
        <joepairman@gmail.com <mailto:joepairman@gmail.com>
        <mailto:joepairman@gmail.com <mailto:joepairman@gmail.com>>> wrote:

             Hi all,

             I have a question about the DITA 1.3 troubleshooting topic,
        and I'm
             sending it to dita-comment because I'm not sure how (if at
        all) this
             question fits in the 1.3 review process.

             Working with the experimental org.dita.troubleshooting plugin
             bundled with Oxygen 16.1, I noticed something about the content
             model for the remedy element. It can be empty, but if it
        has /any/
             content, it must have one of steps, steps-unordered, or
        steps-informal.

             Is this intentional? Might there be a situation where an empty
             remedy element is useful just to hang attributes on? If
        not, perhaps
             it would be easier all round to disallow empty remedy elements.
             Here's the relevant part of the DTD; removing the trailing
        question
             mark would disallow the empty element.

             |<!—                    LONG NAME: Remedy
                 —>
             <!ENTITY % remedy.content
                                     “((%title;)?, (%responsibleParty;)?,
                                       (%steps; |
                                         %steps-unordered; |
                                         %steps-informal;)
                                      )?”
             >|


             Thanks for any info or thoughts.

             Joe




        --
        Bob Thomas
        +1 720 201 8260 <tel:%2B1%20720%20201%208260>
        Skype: bob.thomas.colorado
        Instant messaging: Gmail chat (bob.thomas@tagsmiths.com
        <mailto:bob.thomas@tagsmiths.com>
        <mailto:bob.thomas@tagsmiths.__com
        <mailto:bob.thomas@tagsmiths.com>>) or Skype
        Time zone: Mountain (GMT-7)



    --
    This publicly archived list offers a means to provide input to the
    OASIS Darwin Information Typing Architecture (DITA) TC.

    In order to verify user consent to the Feedback License terms and
    to minimize spam in the list archive, subscription is required
    before posting.

    Subscribe: dita-comment-subscribe@lists.__oasis-open.org
    <mailto:dita-comment-subscribe@lists.oasis-open.org>
    Unsubscribe: dita-comment-unsubscribe@__lists.oasis-open.org
    <mailto:dita-comment-unsubscribe@lists.oasis-open.org>
    List help: dita-comment-help@lists.oasis-__open.org
    <mailto:dita-comment-help@lists.oasis-open.org>
    List archive: http://lists.oasis-open.org/__archives/dita-comment/
    <http://lists.oasis-open.org/archives/dita-comment/>
    Feedback License:
    http://www.oasis-open.org/who/__ipr/feedback_license.pdf
    <http://www.oasis-open.org/who/ipr/feedback_license.pdf>
    List Guidelines:
    http://www.oasis-open.org/__maillists/guidelines.php
    <http://www.oasis-open.org/maillists/guidelines.php>
    Committee:
    http://www.oasis-open.org/__committees/tc_home.php?wg___abbrev=dita
    <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita>
    Join OASIS: http://www.oasis-open.org/__join/
    <http://www.oasis-open.org/join/>




--
Bob Thomas
+1 720 201 8260
Skype: bob.thomas.colorado
Instant messaging: Gmail chat (bob.thomas@tagsmiths.com
<mailto:bob.thomas@tagsmiths.com>) or Skype
Time zone: Mountain (GMT-7)





--
Bob Thomas
+1 720 201 8260
Skype: bob.thomas.colorado
Instant messaging: Gmail chat (bob.thomas@tagsmiths.com) or Skype
Time zone: Mountain (GMT-7)




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