[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Re: Follow-up on longquoteref
I'd be in favor of option #4, too. I don't think we need the duplication and keyref on lq would enable the same functionality. --Scott From: <dita@lists.oasis-open.org> on behalf of Gershon Joseph <gershon@precisioncontent.com> [External Email] If #4 includes removing longquoteref then I vote for it too. I like the idea of using the existing keyref functionality and it follows usage and logic we already have elsewhere. Cheers, Gershon Gershon Joseph | Senior Information Architect | Precision Content Unlock the Knowledge in Your Enterpriseâ
From:
dita@lists.oasis-open.org <dita@lists.oasis-open.org> on behalf of Robert Anderson <robert.dan.anderson@oracle.com> As noted at the TC week, our overlapping capabilities with <lq> and <longquoteref> are more complicated than I thought. The current status is:
That seems odd / inconsistent / excessive, with two ways to express the same source information and only an attribute to specify a title. It came about in DITA 1.2 when the long description links
on <image> were moved to a sub-element, with the same operation done here. Image doesn't have a title, which is probably how we ended up not including the title here. It's really not clear how best to clean this up. I see a few options:
My personal preference is for option four. It simplifies the language by removing an element and several attributes, but makes use of common keyref behavior to provide the same overall function
(connecting the quote to the source of the quote and/or title of the quoted document). But I've also seen very little use of this element, so if anyone thinks it is used more widely, it might be better to go with one of the other options. Thanks, Robert |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]