Next in thread → Next in month →

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

From
Grosso, Paul <>
Date
2007-07-05T20:50:07+00:00
ID
Thread
FW: [dita] Feature 12050--rationalizing href, format, scope, and type attributes
Jeff's email to the list seems to have bounced, so I'm 
forwarding this for him.

 

paul

From: Ogden, Jeff 
Sent: Thursday, 
2007 July 05 13:45
To: 'Erik Hennum'; Grosso, Paul
Cc: 'DITA 
TC list'
Subject: RE: [dita] Feature 12050--rationalizing href, 
format, scope, and type attributes

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:] 
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" 
<> 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
Next in thread → Next in month →