Elaboration of current "13059-like" proposals

After some conversations about the various DITA 1.3 proposals that
    relate to conditional processing, cascades, filtering on branches,
    etc., I've come to see a need to organize the discussion a bit.
    Robert's notes on 13059 indicate that "if needed during proposal
    review, may want to break apart into two issues (overriding cascade
    + filtering within a branch)".

    

    In fact, there are several fairly separate threads that could each
    merit its own omnibus proposal under what we might call a
    "conditional processing theme" for DITA 1.3. I'd like to suggest
    this organization of concerns now so that we can make sure  that at
    least one designated proposal properly represents each set of
    related requirements. Narrowing the issues down to a few high-level
    names might also help with the perception of feature creep. These
    categories also suggest clear topic headings for discussing these
    additions to DITA 1.3.

    

    

    1. "Overriding default cascading rules for metadata." This is a
    suggested title for #13059-accepted as the omnibus proposal for this
    clearly understood requirement. Document both the PTC and IBM
    implementation suggestions so that we can collectively advise on a
    best path forward. Move the "different filtering conditions"
    discussion in 13059 to a different proposal.
    

    

    Directly related proposals under this single theme are:
    
      

        13081-open "Declare when metadata is a blanket assertion vs
        blanket default."

      

        13020-withdrawn (review cascading rules); the discussion at 
          http://lists.oasis-open.org/archives/dita/200904/msg00069.html
        suggests a related spec review for clear wording about behaviors
        of "unconditional content."

    
    

      This has connections to what I've called "New values for
      property/processing attributes" (13007-accepted), see #3.

      

      The concept described by #13059 has been soundly accepted. This
      description simply relates past and still-open proposals that seem
      to group with it, and could be reviewed en masse for completeness.

      

      

      2. "Filtering within a branch." Based on the need to clearly
      excerpt this discussion from #13059, I recommend resurrecting
      #13036-withdrawn as the omnibus proposal for this requirement .
      Seth's approach would enable ditavals that were originally
      associated with an independent branch to continue to provide its
      expected effects (filtering, flagging, exclusivity) whenever the
      branch is referenced into a master map. I have put my name on this
      proposal as champion on Seth's behalf since he was not able to be
      present to stump for it at the time.

      

      Related: 

    
      

        13058-merged "Reference

            a DITA topic in different contexts in the same map (variable
            scoping for multiple versions of single topics in a
            ditamap)"

        PI-based implementation described: 
          http://tech.groups.yahoo.com/group/dita-users/message/19747

          Discussion history summarized: http://tech.groups.yahoo.com/group/dita-users/message/19825
          

    
    
      

        13082-open "Separate ditavals within scope." This proposal adds
        no detail other than a different name.

    
    

      3. "New values for property/processing attributes." This has come
      up subtly amongst the wording of other proposals, but if we treat
      it as a single requirement with a number of related issues, it
      might be more easily considered as part of this emerging trilogy
      of processing requirements. I recommend using #13007-accepted as
      the omnibus proposal for the related discussions.
      

      

      Related:

    
      

        13056-open "Add more conditional attributes to base DITA"

      

        13074-open "Complex filtering definitions within a single props
        attr governed by subject schemes"
        
          

            http://lists.oasis-open.org/archives/dita/201104/msg00002.html

        
      

      

        13075-open "Reconciled metadata schemes for filtering, including
        topicmeta or prolog attributes in subjectref"

      

        13017-open "Filtering attributes and conditional processing"

        Email: http://www.oasis-open.org/apps/org/workgroup/dita-machine-industry/email/archives/200811/msg00005.html

      

        13090-open "Document more open support for @style values" has
        two sub-items:
        
          

            Change @style from enumlist to NMTOKENS.

          

            Document "minimum/allowed" value choices for implementors.

        
      

      

        13057-withdrawn "Allowing filtering on *any* attribute."
        Although withdrawn, the discussion about the issue would be
        worth including in a special topic on this extended class of
        filtering for DITA 1.3.

    
    

      4. "Rationalize the namings/behaviors between metadata elements
      and conditional text attributes." Proposal #13077 has a two clear
      sub-issues:

    
      

        A technical sub-issue: "Enable conditionalizing prolog
        elements." This might be an enabler for some of the cascading
        controls discussed in #1. I recommend creating a new proposal
        number for this specific item.

      

        Normalize the terminology and/or semantics between elements and
        attributes of the same name, such as "author."

    
    

      Related:

    
      

        13040-accepted "Figure out how conditional processing should
        work with metadata elements"

    
    

    5. "Specialize a DITA topic to represent DITAVAL semantics." This is
    a new proposal (not on the list yet) suggested by Seth Park that
    would enable the use of standard DITA conref/keyref and other
    processing features to enable richer enabling of many of the
    previous processing requirements. A prolog domain, for example,
    could help in the rationalized metadata/property attribute naming
    debacle. Standard behaviors would enable the proposals to utilize
    Subjectschemes and other organizing/addressing strategies for
    associating conditional rules to branches of a map.

    

     I'll wait on framing discussions before putting this  particular
    item into the list. Topic or domain? or put the addressing features
    into DITAval? Using topics would actually enable using common
    authoring infrastructure for making updates, managing as a standard
    CMS component, etc.. I tend to see some advantages the more I think
    about it.

    

    -- 

    

      

        
 Don R. Day 

        
 DITA and XML Consultant, Learning by Wrote

          Co-Chair, OASIS
            DITA Technical Committee 

        

          
"Where is the wisdom we have lost in knowledge?

          
Where is the knowledge we have lost in information?"

          
--T.S. Eliot