FW: [dita] Feature 12050--rationalizing href, format, scope, and type at

Erik’s proposal sounds pretty good to me.

He says: “<navref> should have href, format, type and scope attributes (with format defaulted to ditamap)”.

This is OK with me too, but I just want to point out that the format attribute usually inherits its default value from ancestors, so having it default to “ditamap” would make this use of format a little different from most other uses.

-Jeff

From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Thursday, July 05, 2007 2:21 PM
To: Grosso, Paul
Cc: DITA TC list
Subject: RE: [dita] Feature 12050--rationalizing href, format, scope, and type attributes

Hi, Paul:

Regarding <navref> ...

"Grosso, Paul" <pgrosso@ptc.com> wrote on 07/05/2007 09:03:03 AM:
>
> The navref element ... would take more changes to bring
> this into line with the rest of the referencing attributes, and
> maybe that isn't worth the trouble. On the other hand, if it can
> sometimes reference a ditamap and sometimes reference external
> non-dita content, perhaps we do need all the type, format, and
> scope attributes.

The <navref> element preceded the recognition that a <topicref> can refer sensibly
to a DITA map or external Eclipse TOC XML file.

Given that recognition, I'd suggest that the <navref> should have href, format, type
and scope attributes (with format defaulted to ditamap) and should deprecate mapref
in favor of href.

That way, once DITA supports local addition of attributes (which is a possible
windfall as part of the constraints proposal), the <navref> element could be refactored
as a specialization of the <topicref> element with an added, deprecated mapref
attribute -- which might simplify the base map vocabulary a bit in the long term.

Thanks,

Erik Hennum
ehennum@us.ibm.com

dita message