Re: [dita] How should the spec handle statements about rendering expectations?

Indeed, I'm discussing the next generation of docs and
    architecture--where the design (the DITA Model) might associate with
    the necessary spec components on one hand and to the implementations
    on the other. I am linking users to the implementations since data
    specializers may have very different user concerns from the
    authoring side. The spec architecture needs some forethought to
    intent-agnostic setup that adaptively serves the user at their
    application. The spec may be a deterministic map, but other use
    cases may be query-based collections going into the "build"
    (whatever that may mean down the road) or context-driven topic
    selection (like listening stations in a self-guided tour or podcasts
    queued for release by an editorial calendar). 

    

    
On 2/9/2016 2:34 PM, Eliot Kimber
      wrote:

    

    
      

        
I don't disagree with Don's analysis but I think the
          practical reality is that both authors and implementors expect
          to find at least some basic guidance about formatting in the
          spec, if for no other reason than that's where they found in
          the past.

        

        

        
That said, this is DITA. We could have a separate document
          that holds all the formatting discussion and then use parts of
          it by reference as non-normative content in the language
          reference.

        

        

        
Cheers,

        

        

        
Eliot

        

          
----

          
Eliot Kimber, Owner

          
Contrext, LLC

          
http://contrext.com

        

      

      

      

      
        
From:  dita <>
          on behalf of Don Day <>

          Date:  Tuesday,
          February 9, 2016 at 2:06 PM

          To:  dita <>

          Subject:  Re: [dita]
          How should the spec handle statements about rendering
          expectations?

        

        

        

        

          
          
 I agree with Eliot but
            have an even stronger feeling about how to separate OASIS
            from implementation concerns. The <q> element text is
            a good example:

            

            
On 2/9/2016 8:40 AM, Kristen
              James Eberlein wrote:

            

            Authors

                  should not add quote punctuation manually when using
                  the <q>
                  element. 
            That statement is pure specification: this point ensures
            that the resulting authored content is interoperable with
            any DITA-based process, whether rendition, translation,
            editing, or more. I would expect this to be normative
            because it affects the quality of the DITA source.

            

            Processors

                  that render the <q>
                  element SHOULD add
                  appropriate styling, such as locale-specific quotation
                  marks.

              
            This statement however is purely implementation and has no
            impact on the source itself--you could say "should make it
            flashing blue on a reverse magenta background" and it would
            not affect the spec or require OASIS 'SHOULD' treatment.
            Even HTML5 tends to say "send the q element on through to
            the browser and let your locale-dependent CSS take care of
            the punctuation" (although there are issues with full stops
            in quotations -- .</q> vs </q>. -- that may need
            explication in the spec).

            

            But because this sentence was in the spec, it was easy for
            someone to scan and to flag as requiring OASIS
            differentiation, which I argue is pointless here because
            this is not part of the language specification and therefore
            could even be relocated into a non-normative implementation
            document that we've discussed before (my preference now
            being something that could be maintained and freely extended
            on a community wiki like dita.xml.org).

            

            The main point here is just the consideration of
            "interoperable source" as a way to sense normative from
            non-normative (and in this case, potentially relocatable)
            discussion.

            

            
-- 

              
              
 Don R. Day

                Founding Chair, OASIS

                  DITA Technical Committee

                LinkedIn: donrday   Twitter:

                @donrday

                About.me: Don R. Day   Skype:
                don.r.day 

              
 "Where is the wisdom we have lost in
                knowledge?

                Where is the knowledge we have lost in information?"

                --T.S. Eliot  

            

            

            
              
                

                  This
                    email has been sent from a virus-free computer
                    protected by Avast. 

                    www.avast.com
                  
                

              
            
          

        

      
    
    

    
-- 

      
      

        Don R. Day

        Founding Chair, OASIS
          DITA Technical Committee

        LinkedIn: donrday   Twitter:
        @donrday

        About.me: Don R. Day   Skype:
        don.r.day
      

      

        "Where is the wisdom we have lost in knowledge?

        Where is the knowledge we have lost in information?"

        --T.S. Eliot 
      

    

  
 

 
	
	
		This email has been sent from a virus-free computer protected by Avast. 
www.avast.com