Thanks for this detailed discussion.
Let's avoid unnecessary complications. The topicgroup element is
there to provide a way of grouping topicrefs without causing changes
to navigation, or output of titles or anything else.
I think a topicgroup gets its semantic of groupness from:
1. its name
2. its intent
3. the syntax of being parent to a group of child elements.
A topicref that contains other elements also has the semantic of
groupness. The distinguishing feature of topicgroup is not that it
has the semantic of groupness, but that the only semantic
it has is groupness.
To give a topicgroup a navtitle is to contradict its reason for
existence. That is why it has no navtitle attribute.
So, to keep things simple, for ordinary mortals, I propose:
1. The topicgroup element should not be given a navtitle grandchild,
even though permitted by the DTD. If you want to have a navtitle
grandchild then you should use a topicref element (or a
specialisation of topicref, or some other specialization).
2. There is no obligation for a processor to process a navtitle
grandchild of a topicgroup element in any particular way. It might
be preferable to not output anything so that the user might
investigate the absence of expected output and then refer to the
documentation and thence correct the error of their ways. However,
for reasons of speed or simplicity or any other reason, the
processor has no obligation to suppress the output.
There is nothing in the design of a car that prevents me from
signalling right but driving straight on, even though it could have
fatal consequences. We cannot prevent coders from producing
self-contradictory code and don't have an obligation to resolve all
ambiguities.
Regards,
Doug Morrison
Information Architect
http://dita4all.com
On 24/08/2010 21:50, Eliot Kimber wrote:
25ekimber@reallysi.com" type="cite">
On 8/24/10 3:15 PM, "Robert D Anderson" <robander@us.ibm.com> wrote:
That is, I cannot unilaterally specialize from map/topicref and declare,
in
my vocabulary documentation, that any navtitle for my specialization be
ignored.
Why not? You should be perfectly within your rights to have your own
vocabulary, with your own documentation, where your own documentation
states something like "In this specialization of X, I'll process
differently than my ancestor in this specific way." Any processor claiming
support specifically for your vocabulary specialization must follow that
rule; any other conforming DITA processor will (must) use the default
fallback behavior.
The difference is that if the DITA spec says it it's a normative requirement
of all conforming processors that support the mapgroup domain to treat
topicgroup specially, so they have to do it.
Putting anything in my personal vocabulary that overrides the default
behavior required by the DITA spec is going to go nowhere and I would never
depend on it because it would be negating the very value of specialization,
namely stuff happens automatically because of the built-in defaults.
It's one thing to define *additional* semantics for specializations--that's
expected. It's quite another to define *variant* semantics for
specializations--that seems both wrong and ill advised.
So again I say, if groupness is something a topicref either does or doesn't
have, we need a way to say that independently.
I can certainly see that being able to have titled groups would be
handy--that's pretty typical of how I do markup design, so I think it would
be useful to be able to have groups with titles that still do not contribute
to navigation and do not impose their non-navigation behavior onto their
descendants.
On the other hand, I don't think it would be the end of the world to have to
specialize from mapgroup just to get groupness if we did decide to make
topicgroup a special case, so I won't go to the mat if everyone else thinks
that's ok. It just bothers me to have a special case like this.
That is, if I want to design specialized topicrefs that act as groups and
that may also have titles, having to specialize from mapgroup would be OK
since it doesn't impose any inappropriate constraints, even though it would
otherwise be unnecessary.
Cheers,
Eliot