OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


 

> -----Original Message-----
> From: Robert D Anderson [mailto:robander@us.ibm.com] 
> Sent: Thursday, 2007 July 05 10:18
> To: DITA TC list
> Subject: RE: [dita] Feature 12050--rationalizing href, 
> format, scope, and type attributes

> > > - 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?
> 
> Anchorref is supposed to work like other map references - it 
> points to a
> map, and to an ID within that map. The expectation is that 
> the ID will be
> on an <anchor> element, but that's not really important for 
> defining the
> format. I do not think there would be a clear meaning without an ID.

So it sounds to me that we should augment anchorref's current
description which reads: 

 Identifies a location within another map file where this map
 will be anchored (added at runtime, using Eclipse navigation
 integration). For example, anchorref="map1.ditamap/a1" causes
 this map to be pulled into the location of the anchor point a1
 in the other map1.ditamap.

by adding on to the end:

 The anchorref attribute's value is the same as that for the
 href attribute on many other elements.  See "The href attribute"
 for detailed information on supported values and processing
 implications.  It is an error if the anchorref value does not
 include a valid DITA local identifier.  In this case, an
 implementation may (but need not) give an error message, and
 may (but need not) recover from this error condition in some
 implementation dependent way.

> 
> I believe I have primarily seen navref/@mapref pointing to a 
> ditamap, with
> no ID. The only other reference I have seen was to an Eclipse 
> TOC file,
> when the map in question was being integrated with other Eclipse
> information -- <navref mapref="EclipseSource.xml"/>.

I'm not sure what to suggest here.  The navref element has no type, 
format, or scope attribute, so it 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.

I guess I could still use some more input as to what to do for
this attribute.

paul


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]