[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Clarification Needed: Keyref on <image>
On 9/15/09 4:50 PM, "Ogden, Jeff" <jogden@ptc.com> wrote: > @href on image is still required by the DTDs and XSDs or has something > changed in this respect since I last updated and looked at the DTDs and > XSDs (way back on 11 May)? You're right--I was lead astray by my editor, which I thought indicated href was optional, but it is clearly required. Hmm. > With the implementation of @keyref, @href could be optional on image, > but I don't think any of the DITA 1.2 proposals called for that. Not > sure if that was deliberate or if we just didn't think of it at the > time. Of course @keyref existed long before DITA 1.2, so perhaps > someone did think this through long ago and decided that having @href be > required on image was a good idea. I agree that if keyref is intended to be analogous to href then href should be optional since we don't require it on any other linking element to which we have added keyref. For example, <link>, which is listed in 12007 along with <image> (and other elements that have href), does not require href. The language in 12007 does seem to be clear that <image> is like <link> and not like <keyword>. > Having @href be required doesn't hurt anything. If @keyref is used, it > just means that there will always be a fallback value to use if the key > isn't defined or can't be resolved. I think it does hurt to the degree that it's not absolutely necessary and in this case could lead to unexpected failures when authors assume, by analogy, that href is not required on image (because it's not required on other linking elements that take keyref). > So Eliot, are you calling for a change to the DTDs and XSDs to make > @href on image optional? If not, it sounds like the Language Reference > is correct as currently written. I think I might be asking for that: it feels like a bug to me. If keyref can functionally replace href on <image>, then requiring specification of href when you want to only use keyref seems like a serious burden. In the case where users didn't or can't specify a useful URL for the graphic (for example, it's managed by a CMS which does not provide URLs or the URLs would be redundant with a key-based reference) users are likely to put in nonsense values just to satisfy the DTD, making the data worse than it would be with no href (that is, if the keyref can't be resolved, there's the *illusion* of a fallback rather than an immediate understanding that there is no fallback), for example, the user will get a "can't resolve href" message rather than a "can't resolve keyref", which is the real failure. So I can't agree that it doesn't hurt to require href in this case. Cheers, E. > -Jeff > >> -----Original Message----- >> From: ekimber [mailto:ekimber@reallysi.com] >> Sent: Tuesday, September 15, 2009 3:58 PM >> To: ekimber; dita >> Subject: Re: [dita] Clarification Needed: Keyref on <image> >> >> In addition, the current reference entry for image says: >> >> " An href attribute is required on the image element..." >> >> But this is no longer the case in DITA 1.2, since one can specify >> either >> href or keyref. >> >> Either the attribute list is in error (href should actually be > required) >> or >> we need to update the reference entry to indicate that one or both of >> href >> or keyref must be specified. >> >> Cheers, >> >> E. >> >> On 9/15/09 2:54 PM, "ekimber" <ekimber@reallysi.com> wrote: >> >>> In 1.2, the <image> element takes both the href= and keyref= >> attributes. >>> >>> My reading/interpretation/assumption is that for <image>, href= and >> keyref= >>> establish the same relationship, namely from the <image> element to > a >>> graphic object of some sort, where the default presentation intent > is >> for >>> the graphic to be presented with the other content of the topic (as >> opposed >>> to creating a link to the graphic presented in a separate >> presentation >>> space). >>> >>> In particular, I think these two image elements should be >> functionally >>> equivalent: >>> >>> 1. <image href="http://example.com/graphics/image-01.jpg"/> >>> >>> 2. <image keyref="image-01"/> >>> >>> where the effective key binding is: >>> >>> <keydef keys="image-01" >>> href="http://example.com/graphics/image-01.jpg"; >>> format="jpg" >>> /> >>> >>> Is this reading correct? I think it has to be otherwise the normal >> fallback >>> behavior from keyref to href would not make sense for <image>. >>> >>> However, I can imagine that some might have or might think that >> keyref on >>> <image> is intended to function like keyref on <keyword>, where it >>> establishes a link from the image (separately referenced by href) to >> the >>> target of the key reference. I don't think that interpretation is >> what we >>> intended but I want to make sure. >>> >>> Cheers, >>> >>> Eliot >>> >>> >>> ---- >>> Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. >>> email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> >>> office: 610.631.6770 | cell: 512.554.9368 >>> 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 >>> www.reallysi.com <http://www.reallysi.com> | >> http://blog.reallysi.com >>> <http://blog.reallysi.com> | www.rsuitecms.com >> <http://www.rsuitecms.com> >>> >>> >>> > --------------------------------------------------------------------- >>> To unsubscribe from this mail list, you must leave the OASIS TC that >>> generates this mail. Follow this link to all your TCs in OASIS at: >>> https://www.oasis- >> open.org/apps/org/workgroup/portal/my_workgroups.php >>> >> >> ---- >> Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. >> email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> >> office: 610.631.6770 | cell: 512.554.9368 >> 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 >> www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com >> <http://blog.reallysi.com> | www.rsuitecms.com >> <http://www.rsuitecms.com> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]