OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [dita] Proposal 12048 - expanded header for reltable (revised)

I'm with Jeff on the uneasiness about propagating <data>.  Throughout the rest of DITA we are always careful to disavow any knowledge of processing for <data>, such that it can be a catchall for things not yet imagined.  Are we burning any future bridges?

I'd feel better if <data> itself did nothing, but there existed a "may copy" clause that specializations are allowed to invoke.
  <location class="+ topic/data store/location ">...</location>   <!-- This propagates. -->
  <somefeature class="+ topic/data future-o-matic/somefeature ">...</somefeature> <!-- This doesn't propagate, and it would be bad if it did. -->
It'd be easy enough for processors to do this; since the element isn't "really" being copied, only referenced, base processing on topic/data could be a no-op template and override processing on store/location could copy what it needs.  There has to be specialized processing anyway, so it's not saving anyone any coding to change the default.

The part I like least is a topic avoiding receiving a copy of a <data> element by containing its own <data>: that may not be desirable in the context of the future-o-matic specialization, and it also stops us using the relcolspec's <data> with a relcell's <data> additively within the same specialization.

Classify me under "Principle of least astonishment".  But I don't feel too strongly about it, since I don't expect I'll use this feature often, if at all.

The rest of the proposal I like as it is.

Deborah Pickett
Information Architect, Moldflow Corporation, Melbourne

"Ogden, Jeff" <jogden@ptc.com>

17/07/2007 03:00 AM

RE: [dita] Proposal 12048 - expanded header for reltable (revised)

Here are a several more comments on the updated proposal.
I think this version of the proposal is clearer than the previous version.  I think it still needs some work to clarify a few points and some discussion within the TC as a whole to answer some questions.  
I think there are three somewhat different things going on in this proposal.
One is the addition of the <title> element to the relcolspec content model.  I am fine with that, although as you’ll see in some more detailed comments below, I think that this could be made a bit simpler by just using <title> and ignoring the navtitle on topicrefs or topics referenced from topicrefs within a relcolspec.
Two is adding <data> to the relcolspec content model in order to establish default prosperities that will be included in each relcell within the column. This seems to be similar to what we do for <topicmeta> now and I am OK with that.  I am a little uneasy that we only seem to do this processing for <data> within relcolspec and not elsewhere in the document (unless I misunderstand something about <data>, which is always possible).  This is different from <topicmeta> which follows the same rules in and outside of relcolspec. This special case nature of the change makes me a little uneasy.  If others are comfortable with this, I can live with it.
Three is adding <topicref> to the relcolspec content model. And for topicref there seem to be two things going on.  
(i)                   One is using the topicref within a relcolspec as a way to establish default topicrefs that are to be included in each relcell of the column.  This is what I expected from the earlier version of the proposal and I am OK with it. You’ll see a question below about this applying to just top level topicrefs or to all topicrefs.
(ii)                 The other is establishing related links between topicrefs in the relcolspec and topicrefs in the relcells of the column.  I missed this in my reading of the original version of the proposal. This caught me off guard in this version. I am not entirely comfortable with it.  I wonder if we really need to do both?  I wonder if we couldn’t accomplish the same thing by just using topicrefs in the relcolspec as defaults in relcells and using collection-type to enable the establishment of related-links for all of the topicrefs in a relcell including any default topicrefs that are copied from the relcolspec.  I would prefer this to the approach of explicitly saying that topicrefs in a relcolspec always establish related-links to all of the topicrefs in the relcells of a column in addition to including the topicrefs in each relcell by default.  Basing everything on defaults just seems simpler and more consistent and avoids another special case.
If topicrefs within relcolspec are to create related links in some fashion beyond just copying default topicrefs into relcells, I think there needs to be some discussion of how collection-type can or cannot be used to control the generation of these columnwise related links.
Here are some more detailed comments:
Minor: There is a summary line at the top that says “Add header rows to reltables”. This isn’t a big deal, but reltables already allow header rows.  I think this should read “Expand the content model and semantics of relcolspec to include <title>, <data>, and <topicref> elements.”
Minor: In the line near the top that starts out “Currently” it says <relspec> when I think it means <relcolspec>.
In the section on Technical Requirements it says:
… a <topicref> element can avoid receiving a copy of a <data> element by containing a <data> element with the same name or of the same specialization …
I wonder if this should read “… with the same name AND the same specialization …” or if this should be based on just name with the type of specialization ignored.
In the same section it says:
… each top-level <topicref> element contained by the <relcolspec> has related links with each top-level <topicref> in the cells of the same column.
Should this only apply to top-level <topicref>s? I don’t think the horizontal related linking works this way, so why should columnwise related linking work this way? It just seems like another special case which makes things a little more complicated and confusing. Of course if we just use relcolspec to establish defaults, then this issue goes away and columnwise and rowwise related linking is done the same way because there would only be rowwise related linking.
In the section that talks about “order of precedence for establishing the label consistent with other DITA linking:” I wonder if we need anything more than the title element. Just using <title> would be simpler. Basically the rules would be: If the <title> element is present, use it. If the <title> element is not present, generate a group label based on the type attribute on the relcolspec.
Under “Costs” I’d add:
Increase in the size and complexity of the DITA specification. Possible increase in the difficulty for DITA users in understanding, remembering, and applying DITA capabilities due to the increased size and additional special cases.

From: Erik Hennum [mailto:ehennum@us.ibm.com]
Friday, July 13, 2007 7:45 PM
[dita] Proposal 12048 - expanded header for reltable (revised)


Hi, Esteemed TC:

I've updated the reltable header proposal to reflect the clarifications from the correspondence with Jeff Ogden:


For your convenience, a formatted version of the DITA proposal is appended to this note.

While I will be on vacation next week, I believe the plan is to discuss this item on Tuesday and, if no additional discussion is needed, proceed to a vote.

Many thanks to Jeff for giving it such close attention.

Erik Hennum

(See attached file: IssueReltableHeader12048.html)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]