RE: [dita] Props attribute change

["Grosso, Paul" <pgrosso@ptc.com>]

I don't have a lot of data on how much people out
there have legacy with specialized filter attributes.
If we could convince ourselves it was just a small
group of "expert" dita users, we might be able to
live with this incompatibility.

However, assuming we continue to hold to our desire
for no incompatibilities, I think it's okay to go
with Robert's suggested fix below for 1.x.  I don't
think the downsides are too problematic.

paul

> -----Original Message-----
> From: Robert D Anderson [mailto:robander@us.ibm.com] 
> Sent: Monday, 2006 June 26 18:18
> To: dita@lists.oasis-open.org
> Subject: [dita] Props attribute change
> 
> 
> 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.