Fwd: Re: [dita-lightweight-dita] LwDITA DTD/feature questions

For TC attention.

    

    

    
Best,

      Kris

      

      Kristen James Eberlein

      Chair, OASIS DITA Technical Committee

      Principal consultant, Eberlein Consulting

      www.eberleinconsulting.com

      +1 919 682-2290; kriseberlein (skype)

      

    

    

      

      -------- Forwarded Message --------
      
        
          

            Subject:
            
            Re: [dita-lightweight-dita] LwDITA DTD/feature questions
          

          

            Date: 
            Mon, 5 Jun 2017 12:18:56 -0500
          

          

            From: 
            Robert D Anderson <>
          

          

            To: 
            Michael Priestley <>
          

          

            CC: 
            , Carlos Evia
              <>,
              
              <>
          

        
      
      

      

      
Interesting ... I hadn't even noticed that we're
          including specialized <object> elements but not
          including <object> itself. The pains of joining the
          committee late, I suppose.

        

        I wouldn't want to call LwDITA topicref element
          "specialized from" full DITA topicref, just because working on
          the DITA 1.3 spec made me far more obsessive over terminology
          than I ever was for 1.2 and earlier. But in theory, you could
          say that LwDITA <topicref> is a constrained version of
          full DITA <topicref>, while <keydef> both
          specialized from + less constrained than full DITA topicref. 

        

        This all feels strange but I'm trying to think of
          it as "something new" rather than "something DITA that follows
          the existing definition of specialization". Regardless of how
          we handle it, I do think that this calls for much closer
          attention to how we describe specialization in LwDITA. 

        

        With DITA 1.3 today -- every specialization must
          refer back to something in the base. So any application that
          supports the base + supports specialization has at least
          *some* level of support for every specialization.

        

        Today, LwDITA spec is declaring specializations
          of an element that is not part of LwDITA. Which got me tugging
          a lot of threads:

        1. Can somebody else create new specializations
          of <object> in LwDITA, or must they be specializations
          of the existing multimedia elements?

        2. If they can specialize base <object>:
          should applications be expected to support <object>,
          even if it's not part of LwDITA? I think the answer has to be
          "yes" or else those specializations would have no fallback
          support.

          3. If yes - can a LwDITA user create their own doctype that
          actually includes <object> directly? I'd have said "no"
          when I started this email...

        4. If a LwDITA user can use or specialize
          <object> (which isn't in LwDITA), can they do the same
          with other elements like <cite>?

        5. In general: if the LwDITA spec can specialize
          by pulling full DITA features that are not in LwDITA (like
          object, like keydef/@processing-role) ... can LwDITA users do
          the same? 

        

        For #5 the answer must be no. Because if it's
          yes, then LwDITA applications must be prepared for specialized
          LwDITA to have any core DITA feature ... which means there is
          no such thing as a LwDITA application, only full DITA
          applications. But if the answer really is "no" -- that is,
          "The spec can pull core features into specializations but you
          cannot" -- then I'm very curious to see how we explain that.

        

        For what it's worth - tugging at all of these
          threads got me in a bit of a panic, so I sent some messages to
          Michael, who clarified some things:

        - <object> is not part of LwDITA, so if you
          specialize from <object>, you should not expect LwDITA
          apps to work.

        - Same for other elements and attributes of full
          DITA not in LwDITA

        - Meaning <keydef> can use @processing-role
          but if you specialize your own topicref and use it, you should
          not expect it to work. 

        - But LwDITA apps should support it on
          <keydef> because that's the spec, and it's still a nice
          tidy subset of full DITA.

        - And you could specialize <keydef>, or
          <video>, or any LwDITA "core" element, and use what's
          there, but as usual you can't add your own new stuff

        

        All of which sounds reasonable / justifiable,
          just calls for us to write up a really nice explanation to
          make sure this is clear for both LwDITA architects and for
          LwDITA implementers.

        

        
          
            

              Regards,
                
Robert D.
                      Anderson 

                    DITA-OT lead and
                      Co-editor DITA 1.3 specification,

                      Digital Services Group 

              
              
            

            

              
                
            

            

              E-mail: 

                Digital
                      Services Group 
              
                

              
            

            

              11501 BURNET
                    RD,, TX, 78758-3400, AUSTIN, USA 
            

            

               

              
            

          
        
        

        

        Michael Priestley---06/05/2017
          10:17:43 AM---Hi Robert, For processing-role on topicrefs vs
          keydef -

        

        From: Michael
          Priestley/Toronto/IBM

        To: "Robert
          D Anderson" <>

        Cc: ,
          Carlos Evia <>,
          ""
          <>

        Date: 06/05/2017
          10:17 AM

        Subject: Re:
          [dita-lightweight-dita] LwDITA DTD/feature questions

      

      

      

      

      Hi Robert, 

      

        For processing-role on topicrefs vs keydef - 

      

        If you think of it as both topicref and keydef being
        derived/specialized/constrained from full topicref, there's no
        issue from a DITA perspective. 

      

        If we want keydef to be considered as a specialization *within*
        lightweight DITA then you are correct. 

      

        But we do have other specializations in LwDITA that are clearly
        not specializations *within* LwDITA. For example, the multimedia
        specializations are off of object, which we're not even
        including in LwDITA. 

        

        Michael Priestley, Senior Technical Staff Member (STSM)

        Enterprise Content Technology Strategist

         

      

      

      

        From: "Robert D Anderson"
        <> 

        To:  

        Cc: Carlos Evia <>,
        ""
        <> 

        Date: 06/05/2017 11:00 AM 

        Subject: Re: [dita-lightweight-dita]
        LwDITA DTD/feature questions 

        Sent by: <>
      

      

      

      

        Not that I'm out to make things more complicated, but with
        regards to @processing-role...

        

        It's sort of a one-stop-shop for several original DITA
        attributes. It means "Don't put this in the TOC, don't generate
        links based on this instance, don't print, etc". None of those
        attributes are part of LwDITA, and that seems right to me, as
        they're for more complex scenarios. 

        

        But without @processing-role, our key definitions in particular
        become full-on parts of the TOC, link structure, and so on. We
        need to have that attribute, as the only way to distinguish
        something that's just part of the map for reference (most often,
        keys) and something that's actual content. The <keydef>
        element in particular needs to set
        processing-role="resource-only" as a default value in order to
        work properly. 

        

        And to answer the logical follow-up ... I don't think we can
        have @processing-role *without* having it on <topicref>.
        The <keydef> element is specialized from <topicref>,
        and if we're adding a core processing attribute on the
        specialization (but not on the base), then we've really broken
        the rules of specialization.

        

        If it helps anything, I liked the answers to all the other
        questions...
      
        
          

            Regards,
              
Robert D.
                    Anderson 

                  DITA-OT lead and
                    Co-editor DITA 1.3 specification,

                    Digital Services Group 

            
            
          

          

            
              
          

          

            E-mail: 

                Digital
                      Services Group 
            
              

            
          

          

            11501 BURNET RD,, TX,
                  78758-3400, AUSTIN, USA 
          

          

            
          

        
      
      

      

      

      Alan Houser ---06/05/2017 09:23:07 AM---Hi Mark and
        Carlos, Thanks! All answers align with my expectations.
        Apologies for asking

        

        From: Alan Houser
        <>

        To: Carlos Evia <>

        Cc: ""
        <>

        Date: 06/05/2017 09:23 AM

        Subject: Re: [dita-lightweight-dita]
        LwDITA DTD/feature questions

        Sent by: <>

      

      

      

      Hi Mark and Carlos,
      
Thanks! All answers align with my expectations. Apologies for
        asking about @outputclass -- that's definitely there. 

      
-Alan 

      
--- 

      

        On 6/5/17 6:21 AM, Carlos Evia wrote: 

        The only filtering attribute available in LwDITA is @props. My
        students used it last semester in XDITA topics. 

        I think processing-role is too complex for LwDITA map users...
        just my opinion. 

        

        Carlos

        

        -- 

        Carlos Evia, Ph.D.

        Director of Professional and Technical Writing

        Associate Professor of Technical Communication

        Department of English

        Center for Human-Computer Interaction

        Virginia Tech

        Blacksburg, VA 24061-0112

        (540)200-8201

        

        

        On Sun, Jun 4, 2017 at 11:02 PM, Alan Houser <>
        wrote: 

        Colleagues,

        

        A few questions about the Lightweight DITA DTDs and LwDITA
        features --

        

        - The content model and attribute set for <data> is
        different in maps and topics (content model: <data> in
        <topic> allows #PCDATA; <data> in <map> does
        not. And the attributes are different). Is that intentional?

        

        - LwDITA does not provide the DITA filtering attributes? (O.K.
        with me; just confirming).

        

        - LwDITA does not provide a generic metadata container attribute
        (e.g., @outputclass)?

        

        - Should we provide @processing-role on <topicref>? I'm
        thinking of the use case of referencing a "keydef-only" ditamap
        (@processing-role = "resource-only").

          

          -Alan

          

        

      

          -- 

          Alan Houser

          Group Wellesley, Inc.

          Consultant and Trainer, Technical Publishing

          arh on Twitter

          412-450-0532