OASIS Darwin Information Typing Architecture (DITA) TC

 View Only

  • 1.  Feature 12050--rationalizing href, format, scope, and type attributes

    Posted 06-28-2007 21:30

    Attachment(s)

    htm
    12050-sum.htm   21 KB 1 version
    htm
    12050.htm   41 KB 1 version


  • 2.  Re: [dita] Feature 12050--rationalizing href, format, scope, and typeattributes

    Posted 07-05-2007 00:08 

    "Grosso, Paul" <pgrosso@ptc.com> wrote
on 29/06/2007 07:30:22 AM:

    
> The attached 12050.htm is an HTML document showing the
    
> analysis of use of these attributes in DITA 1.1 and
    
> detailing the suggested spec changes for DITA 1.2.
    

    Hi Paul,

    This looks like a good way to sanitize the proliferation
of meanings for these attributes.

    Some comments (which I've already sent you privately,
but I'm repeating here to foster some comment from others):

    - An empty @href is a valid URI (it tends to mean
the base directory, by default the one that contains the current document).
 The proposed wording doesn't say that empty @href is special, so
the default meaning should still apply.  This isn't how DITA-OT handles
empty @hrefs, which it assumes are the same as absent @hrefs.  (I
think that DITA-OT does this to facilitate handling of <topichead>.)
 Is DITA-OT off-spec, or is there a reason to define empty @href specially
in the DITA spec?

    - @longdescref getting @...scope and @...type brethren:
Is this the right direction to go?  Is it better to move the longdesc
to an element and give it the standard @href, @scope, @format and @type
attributes?  There was apparently discussion about this at this week's
TC teleconference.

    - map/@anchorref and navref/@mapref: I don't even
know if these are URI-references, whether they have fragment suffixes or
not, or whether they are something else entirely.  If they are URI-ish,
then now is a good time to pin down their format.  Can anyone who
uses them speak on their behalf?

    Thanks again for putting together such a thorough
document.

    --
    
Deborah Pickett
    
Deborah_Pickett@moldflow.com



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

    Posted 07-05-2007 14:12 
     

> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 4.  RE: [dita] Feature 12050--rationalizing href, format, scope, and typeattributes

    Posted 07-05-2007 15:18 
    Hi Paul -

> > is special, so the default meaning should still apply.  This
> > isn't how DITA-OT handles empty @hrefs, which it assumes are
> > the same as absent @hrefs.  (I think that DITA-OT does this
> > to facilitate handling of


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

    Posted 07-05-2007 16:03 
     

> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 6.  RE: [dita] Feature 12050--rationalizing href, format, scope, and typeattributes

    Posted 07-05-2007 18:21 
    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