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)
- From: Deborah_Pickett@moldflow.com
- To: dita@lists.oasis-open.org
- Date: Tue, 17 Jul 2007 17:33:32 +1100
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.
<relcolspec>
<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. -->
</relcolspec>
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
Deborah_Pickett@moldflow.com
"Ogden, Jeff"
<jogden@ptc.com>
17/07/2007 03:00 AM
|
To
| <dita@lists.oasis-open.org>
|
cc
|
|
Subject
| 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.
-Jeff
From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Friday, July 13, 2007 7:45 PM
To: dita@lists.oasis-open.org
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
ehennum@us.ibm.com
(See attached file: IssueReltableHeader12048.html)
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]