OASIS Darwin Information Typing Architecture (DITA) TC

The @cascade attribute coming in DITA 1.3 is a CDATA attribute with 2 pre-defined values to control how attribute values merge during a cascade process. There was a lot of discussion about making this CDATA to allow for the case where applications need to support more conditions than we have now. The discussion led to the design points that: 1. The standard values (merge or nomerge) must come first if using multiple values 2. App-specific tokens must be in upper case, potentially followed by a list of affected attributes A sample would be something like "merge APPTOKEN audience platform". In the review Chris Nitchie pointed out that this is inconsistent with other parts of the spec: 1. For the chunk attribute, we state that app-specific tokens must begin with a prefix, such as app:chunkToken. 2. If a token in @cascade is followed by a list of attributes, it becomes very similar to the groups allowed in property attributes. Chris and I both agree that this extension mechanism is unlikely to be used often, so we should not spend much time worrying about it. At the same time, it would be more consistent (and simpler for implementations) if we change the syntax of application specific tokens to match similar usage elsewhere. This would change the previous example to something more like: "merge app:token(audience platform)" or just "merge app:token" I'd like to propose making this change in response to Chris's review comment on the cascade mechanism. Thanks - Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit ( http://dita-ot.sourceforge.net/ )

This seems like a good idea to me. Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com On 4/7/14, 3:27 PM, "Robert D Anderson" <robander@us.ibm.com> wrote: >The @cascade attribute coming in DITA 1.3 is a CDATA attribute with 2 >pre-defined values to control how attribute values merge during a cascade >process. > >There was a lot of discussion about making this CDATA to allow for the >case where applications need to support more conditions than we have now. >The discussion led to the design points that: >1. The standard values (merge or nomerge) must come first if using >multiple values >2. App-specific tokens must be in upper case, potentially followed by a >list of affected attributes > >A sample would be something like "merge APPTOKEN audience platform". > >In the review Chris Nitchie pointed out that this is inconsistent with >other parts of the spec: >1. For the chunk attribute, we state that app-specific tokens must begin >with a prefix, such as app:chunkToken. >2. If a token in @cascade is followed by a list of attributes, it becomes >very similar to the groups allowed in property attributes. > >Chris and I both agree that this extension mechanism is unlikely to be >used often, so we should not spend much time worrying about it. At the >same time, it would be more consistent (and simpler for implementations) >if we change the syntax of application specific tokens to match similar >usage elsewhere. This would change the previous example to something more >like: >"merge app:token(audience platform)" >or just >"merge app:token" > >I'd like to propose making this change in response to Chris's review >comment on the cascade mechanism. > >Thanks - > >Robert D Anderson >IBM Authoring Tools Development >Chief Architect, DITA Open Toolkit ( http://dita-ot.sourceforge.net/ )