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

[Robert D Anderson <robander@us.ibm.com>]

First - you're certainly right that this is "unavoidable" rather than
"unintended". The issue was known when we added <navtitle>, and could not
be avoided.

Second - as you say, we would ideally have a specialized topicmeta, but
this was ruled out in discussion due to the backwards compatibility issue.

I don't have a big problem with changing this so that topicgroup with a
navtitle still uses the navtitle, on the grounds that it's easier for all
concerned; however, that does run counter to the stated description of the
topicgroup element. It's well within the rights of the spec to declare new
behaviors associated with a new element, even if those require additional
processing, so I don't think it's out of bounds for the spec to say "on
this specialized element, the following item has no effect".

I think we should discuss this again at next week's call. Changing the
behavior of topicgroup on this item will require a vote, since this
described behavior was specifically called out in the proposal for the new
<navtitle> element.

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit



From:	Eliot Kimber <ekimber@reallysi.com>
To:	Eliot Kimber <ekimber@reallysi.com>, "Bruce Nevin (bnevin)"
            <bnevin@cisco.com>, Doug Morrison <dmorrison@dita4all.com>,
            dita <dita@lists.oasis-open.org>
Date:	08/24/2010 01:44 PM
Subject:	Re: [dita] DITA 1.2 Review Comment: Thoughts on topicgroup,
            navtitle, and locktitle



The real answer would be to specialize <topicmeta> specifically for
<topicgroup> in the mapgroup domain in order to disallow <navtitle>. That
would impose the same constraint that omitting @navtitle imposes and would
be a more complete expression of the intention of topicgroup.

Of course, such a change would not be backward compatible with 1.1, which
is
why we didn't do it in the first place.

Thus the availability of <navtitle> as a descendant of <topicgroup> is an
unavoidable consequence of that new markup design (which is itself demanded
by localization requirements).

Cheers,

E.

On 8/24/10 12:10 PM, "Eliot Kimber" <ekimber@reallysi.com> wrote:

> On 8/24/10 10:43 AM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote:
>
>> For the confusion, here's a proposed clarification:
>>
>> In DITA 1.2, the <navtitle> element is optionally available within the
>> <topicmeta> element. This has the unintended effect of making it
>> possible to specify <navtitle> within a <topicgroup>. Since the
>> <topicgroup> element is meant as a non-titled grouping element, adding a
>> <navtitle> element to the <topicgroup> element has no defined purpose,
>> and processors must ignore the title. Processors may (but need not)
>> issue a message when ignoring the title.
>
> I would correct this in two ways:
>
> 1. c/unintended/unavoidable/
>
> 2. Rather than saying that processors must ignore the title I think we
must
> say that specifying a <navtitle> for <topicgroup> effectively makes it
into
> a topic head.
>
> That is, the semantics of topicrefs, as far as the DITA spec is
concerned,
> are entirely a function of what properties are or are not present for a
> given topicref instance. The specializations in the map group domain are
> simply syntactic conveniences, but they can't change the essential
meaning
> of a given combination of properties.
>
> Thus <topicgroup> is a syntactic convenience but cannot *impose* the
> semantic of groupness in the presence of an explicit navigation title.
>
> Or said another way, the interpretation of any topicref, in terms of the
> DITA-defined semantics, should be invariant if I generalize specialized
> topicrefs into the base topicref.
>
> Thus,
>
> <topicgroup>
>  <topicmeta>
>    <navtitle>foo</navtitle>
>  </topicmeta>
> </topicgroup>
>
> generalizes into
>
> <topicref>
>  <topicmeta>
>    <navtitle>foo</navtitle>
>  </topicmeta>
> </topicref>
>
> And would be correctly interpreted as a topic head, not a topic group.
>
> If this is not the case then I cannot have a completely generic topicref
> handler that simply looks at the presence or absence of a navigation
title
> or a resource reference in order to distinguish topicrefs, topicheads,
and
> topic groups, but I would have to have a special case specifically for
> mapgroup-d/topicgroup.
>
> I think requiring that special case would be very very wrong.
>
> Cheers,
>
> Eliot
>
> --
> Eliot Kimber
> Senior Solutions Architect
> "Bringing Strategy, Content, and Technology Together"
> Main: 512.554.9368
> www.reallysi.com
> www.rsuitecms.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>

--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php