Re: [dita] DITA 1.2 Review Comment: Thoughts on topicgroup, navtitle,and locktitle

[Doug Morrison <dmorrison@dita4all.com>]

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:

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