Next in thread →
Next in month →
RE: [dita] Simple table specializations (e.g. property tables)
Hi, Robert and Paul: Good catch and analysis. Option 1 (requiring the empty cells) would invalidate topic instances that are valid for DITA 1.0 and isn't optimal for authors. Option 2 (defaulting a colnum attribute in <stentry> specializations) has a minor hiccup -- what if we had a properties table with only <proptype> and <propdesc> columns (a common case)? We'd want to format it as a two-column table instead of inserting an empty column for <propvalue>. So, the processing would need to treat the colnum as a column identifier with a pre-defined sequence with respect to the other column identifiers rather than as an actual column assignment. If that behavior would be confusing to authors and designers, we could modify Option 2 to provide a colname attribute on <stentry> and a colnames attribute on <simpletable> that lists the allowed colnames in order. Either way, if the row allowed a choice of specialized <stentry> elements in the column, the specialized elements could share the same column identifer. Option 3 (aligning cells in columns based on the most specialized class) has the strong appeal of processing based on semantics, but I can't think of a way to meet Robert's objections without requiring processors to match row instances against the row content model. We should steer clear of custom generalization code. Currently, people can exchange normalized content and generalize as needed. It would be unfortunate if people sometimes had to send along custom generalization code. (Hmmm. Unless the generalization code could be normalized with the content?) Other thoughts? Erik Hennum Robert D Anderson/Rochester/IBM@IBMUS Robert D Anderson/Rochester/IBM@IBMUS 01/05/2006 12:19 PM To cc Subject RE: [dita] Simple table specializations (e.g. property tables) Hi Paul, I suspect that what you're looking for is not in the spec (sometimes I wonder, are any of your questions ever answered in the spec?), but I haven't looked to be sure. This gets in to one point about specializations, which is that some of them really require processing overrides to get good output. In cases like that, I tend to think that there are two options. One is to keep the class attributes when generalizing, and keep the processing override. The second is to have a migration as part of your generalization -- in the case of property tables, it would add empty cells as needed. For the suggested changes to the spec: 1. If we disallow optional cells, then we limit further specialization, or make it more awkward. For example, if we require all three cells in a property row, then a specialization of reference using only two of the columns will still have a required empty column. 2. Adding a colnum attribute edges us closer to the CALS/Exchange tables, which decreases the simplicity of the simpletable... but otherwise doesn't seem to be a problem. 3. If we require that each column have a unique type/name/class value, then it means we cannot have rows like this one: ( name, street, (stateName | provinceName), postalcode?) In that case, the <stateName> and <provinceName> elements would need to line up in the same column, even though they do not have the same type. I do not know of any specializations like this today, but they are possible. I think I'd be tempted to say this: If you specialize a table in a way that implies empty cells, you have three options. First, you can require that your specialized processing stay with the files, even when the files are generalized. Second, you can provide a generalization/migration routine that allows you to fall back without breaking the content. Otherwise, you should consider requiring each cell to appear in each row, even if some of those cells may be empty. Alternatively, we could say: By default, processing should line up any unique simpletable entry in its own column. [insert details on how to tell which comes first when 2 rows each have a unique entry. Insert specific details on how to tell if an entry is unique -- would <proptype> be allowed in the same column as a specialized proptype?] If multiple elements can use the same column, then you must provide special processing. [Insert any best practices on overriding generalization, when removing class attributes]. In the second alternative, the state/province example would still require users to do something for good fallback or generalization, but it would fix tables that use the <properties> model. Any thoughts? Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit "Paul Prescod" <paul.prescod@bla stradius.com> To "Paul Prescod" 12/29/2005 02:42 <>, PM <> cc Subject RE: [dita] Simple table specializations (e.g. property tables) To put this question another way: where in the DITA specification does it say that simple table specializations with optional cells should operate in the intuitive fashion where elements are lined up by element type rather than the way that generalization otherwise works where specialized element types are ignored except in the presence of overrides. > -----Original Message----- > From: Paul Prescod [mailto:] > Sent: Thursday, December 29, 2005 12:11 PM > To: > Cc: > Subject: [dita] Simple table specializations (e.g. property tables) > > Property tables inherit from simple tables, but it seems to > me that the semantics of the two do not line up directly. > Consider the following property table (from the DITA specification): > > <properties> > <prophead> > <proptypehd>Visual Element</proptypehd> > <propvaluehd>Value</propvaluehd> > <propdeschd>Implication</propdeschd> > <property> > <proptype>color</proptype> > <propvalue>red</propvalue> > <propdesc>depicts anger</propdesc> > </property> > <property> > <propvalue>green</propvalue> > <propdesc>depicts permission</propdesc> > </property> > </properties> > > Note that the last row lacks a "proptype". > > Now consider the generalization of this: > > <simpletable> > <sthead> > <stentry>Visual Element</stentry> > <stentry>Value</stentry> > <stentry>Implication</stentry> > </sthead> > <strow> > <stentry>color</stentry> > <stentry>red</stentry> > <stentry>depicts anger</stentry> > </strow> > <strow> > <stentry>green</stentry> > <stentry>depicts permission</stentry> > </strow> > </simpletable> > > What tells a formatter working on this content that the > stentry should go in the SECOND column rather than the FIRST > column? In fact, the DITA toolkit puts the word "green" in > the first column as does XMetaL DITA Edition (when working > with arbitrary specializations). Is there any application out > there that works otherwise? With arbitrary specializations of > simple tables? > > I can think of three solutions to the problem, all requiring > changes to the DITA specification. > > 1. Simply disallow specializations of simple tables that have > optional cells. Instead, authors should just use empty > elements to represent missing data. This is BY FAR the > simplest solution for implementors. > > 2. Add metadata (probably through fixed attributes) allowing > elements to be aligned. E.g. a "colnum" attribute for each cell. > > 3. Declare that specializations of simple tables MUST use > unique element type names for columns. Then columns could be > aligned by the class attribute. > > Paul Prescod >
Next in thread →
Next in month →