Props attribute change

[Robert D Anderson <robander@us.ibm.com>]

I really hate to bring this up, but -

With the current props attribute proposal, the design makes backwards
incompatible changes for specialized document types (though not for the
base DITA standard). Existing specialization DTD or Schema modules will
become invalid, although all document instances will remain valid.

With each of the 4 existing filter attributes, the current design will move
them to domains (this is already implemented in the DTD's I've posted).
They are then automatically added back to every element that allows props.
They will appear as optional CDATA attributes on every element that allows
props.

Now assume an existing specialization creates a specialized list item. On
that new list item, the audience attribute is restricted to a set of 5
values, and is also required. Once DITA 1.1 is released, the audience
attribute will be defined globally as CDATA - any document type that
redefines it will become invalid. This is not backwards incompatible for
document instances because 1) required attributes may become optional, 2)
limited attributes may become CDATA, and 3) missing attributes may be
added. However, the specialization definition itself is no longer valid.

I think that the only fix to this is to not move the 4 existing filter
attributes to domains in 1.1. We will still add @props. All new specialized
attributes will come off of props. When we are able, we will move those 4
to domains and treat them like everything else. The downsides are that
architecturally it is a bit confusing, and technically programs that filter
will have to look for the 4 traditional values outside of the code that
looks for new values.

Does this make sense? I tried to make this note as short and clear as
possible so that people would read it, but the result may be too little
explanation...

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787