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

[Robert D Anderson <robander@us.ibm.com>]

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 <topichead>.)
...
> Michael, Robert, Don, et al., is it the case that @href=""
> has special meaning for DITA?

If I remember correctly - and this is going back a ways - the toolkit
behavior was based on user complaints. The users had an href attribute,
which they removed by deleting the content in an attribute editor, but they
were left with href="". Processes tried to evaluate that as a file or
element reference, resulting warnings about a missing target, or something
like that. I believe we did the same thing at one point for conref="",
which (seemingly) has even less meaning. Of course the spec should not be
defined based on toolkit behavior - if the spec says that href="" or
conref="" actually mean something, then the toolkit will need to be
updated.

> > - @longdescref getting @...scope and @...type brethren: Is
...
> Who took the action to develop this proposal?

Michael Priestley took that action, or was volunteered when nobody else
spoke up.

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

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"/>.

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787 (Good Monday & Thursday)

"Grosso, Paul" <pgrosso@ptc.com> wrote on 07/05/2007 09:10:06 AM:

>
>
> > -----Original Message-----
> > From: Deborah_Pickett@moldflow.com
> > [mailto:Deborah_Pickett@moldflow.com]
> > Sent: Wednesday, 2007 July 04 19:07
> > To: DITA TC list
> > Subject: Re: [dita] Feature 12050--rationalizing href,
> > format, scope, and type attributes
> >
> > "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.
>
> > - 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?
>
> OT behavior does not belong in the spec, but we should clarify
> things if some values of @href do not mean what they mean
> for a URI reference.
>
> I don't see anything in the spec to indicate that an empty
> string for topicref's href means anything special.  If, in
> fact, it is necessary for @href="" to mean something special
> in DITA's case, we need to include that information in the spec.
>
> Michael, Robert, Don, et al., is it the case that @href=""
> has special meaning for DITA?
>
> >
> > - @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.
>
> I have forgotten, and I haven't seen Tuesday's minutes yet.
>
> Who took the action to develop this proposal?
>
> >
> > - 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?
>
> I agree with Deborah that we should probably clarify these
> attributes too, but I could use some help in doing so.
>
> Is there any reason we shouldn't give these two attributes
> the same standard description that we give to @href?
>
> paul