Elaboration of current "13059-like" proposals

["Don Day (LbyW)" <donday@learningbywrote.com>]

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