[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Props attribute change
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]