[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Proposal 12048 - expanded header for reltable
|
Paul Grosso asked me to comment on this proposal when it first came up for discussion two and a half weeks or so ago. It took me a little while to get around to writing something down and a little longer to get to the point where I could post to the list myself. Sorry for the delay.
My first reaction to this proposal was that it was making a part of the DITA specification that is already pretty complicated and probably not all that well understood by many people even more complicated. I still have that concern and I’ll write a separate note about that since I think my concern is really more about the complexity and size of the DITA specification as a whole and not really about the additional complexity added by this specific proposal.
My second reaction was that I didn’t understand the discussion about “constraints” and wondered if this was a new capability. After reading the proposal over a few more times I think I figured out that the business about constraints isn’t anything new and in fact there aren’t really any constraints imposed by the relcolspec or at least not any constraints that are enforced. Rather than constraints the relcolspec might be viewed as providing a hint to an author about how the column in the reltable is to be used. Is my newfound understanding correct?
Today the attributes on the relcolspec as well as the metadata elements included within any topicmeta group that is included in the relcolspec are used to provide inherited values for items in the relcells of the particular column. This inheritance is the same as the inheritance of attribute values and metadata that occurs elsewhere within a DITA map.
The proposal calls for the addition of topicref to the content model of relcolspec. This would provide a feature somewhat similar to the inheritance that already exists for topicmeta. It is different in that topicrefs themselves aren’t inherited elsewhere in DITA documents, although some of their attributes might be. Is this difference OK? Is there a need to merge attribute values from a topicref in a relcolspec with attribute values on a matching topicref that appears explicitly in a relcell in a fashion similar to what would be done for topicmeta information that is given in both places?
I am less clear about including the data and data-about elements in the content model for relcolspec. Is this just a matter of copying the data and data-about elements from the relcolspec into the relcell during processing in a manner that is like what is done for topicmeta and which might be done for topicref or is there more to it than that? Is there a need to merge matching data or data-about elements in some fashion? Are data and data-about inherited elsewhere within DITA documents? Are data and data-about anything more than additional types of metadata? And if so, could these elements or specializations more simply be included within topicmeta rather than directly within relcolspec?
There is a comment that says: “Base processing could also use the title of the first topic from the <relcolspec> as the label for the grouped related links from the column in the output for each topic referenced in other columns.” I guess I’m not sure why just the title form the first topicref would be used. And is this the actual title from the topic that is referenced or the value of the navtitle attribute on the topicref? Providing a way to specify the label to use for a related link group seems like a good idea, but is using a title from a topicref the right way to do this? Would a topichead element work for this as well or better? Or would allowing a title element to appear within a relcolspec be a more straight forward approach?
There is a note that says: “The specification might also consider whether a <data> element in a relcell would distribute to other columns in the same row (providing a horizontal equivalent to this vertical distributive capability).” This seems sort of vague. Is the proposal to add this capability? If this were done, would this just be adding the ability to specify defaults from cell to cell within a row or is something more implied? Would this just work for data elements in the first column? Is it controlled by the collection-type attribute or some other mechanism? Is this really looking for a relrowspec element to play the same role for rows as relcolspec does for columns?
-Jeff
From: Erik Hennum
[mailto:ehennum@us.ibm.com]
Hi,
Esteemed TC: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]