OASIS Darwin Information Typing Architecture (DITA) TC

 View Only
Back to discussions
Expand all | Collapse all

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

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

    Posted 07-05-2007 20:50 
    






    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: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


Related Content