Re: [dita] Review comment for TC discussion: navref

[Eliot Kimber <ekimber@contrext.com>]

The navref element is problematic for a number of reasons, but it's what
it is. It seemed reasonable at the time I was doing my review that it
should allow @keyref but I wouldn't object to just leaving it as it is.

The value of having @keyref would be to simply have the usual indirection
advantages of using keys, but since navref doesn't actually use URI
addressing (mapref is not a URI address, it's a processor-specific magic
value that the processor uses to hook up the navigation), I can certainly
support an argument that @keyref is not appropriate.

So I say leave the spec as written.

Cheers,

E.

—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com




On 11/5/14, 12:12 PM, "Robert D Anderson" <robander@us.ibm.com> wrote:

>Eliot noticed that the specification draft did not list @keyref as a
>valid attribute for <navref>:
>http://ditaweb.com/oasis-dita/#/00074601-DA$00073994-DB$%3Cnavref%3E
>
>That actually matches the DITA 1.2 specification - although the DTDs we
>shipped did include it. I was so certain @keyref was not available on
><navref> that I didn't note the disconnect when changing the 1.2 level
>attribute table into the 1.3 version.
>
>So, the questions for the TC:
>1. Should @keyref be legal here? Technically the specification wins so in
>1.2 it was (technically) invalid. But in most situations like this, when
>the DTD had an attribute but spec did not, we've resolved the disconnect
>by making the attribute legal.
>
>2. In nearly all other cases with @keyref, if the key is undefined, @href
>is a fallback. In this case, <navref> does not use @href (it uses
>@mapref). If we do add @keyref to <navref>, should @mapref be used as the
>fallback when a key is undefined?
>
>
>Robert D Anderson
>IBM Authoring Tools Development
>Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)