[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: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]