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.
-Jeff
From: Erik Hennum
[mailto:]
Sent: Friday, July 13, 2007 7:45
PM
To:
Subject: [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:
http://www.oasis-open.org/apps/org/workgroup/dita/download.php/24622/IssueReltableHeader12048.dita
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)
