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: <> on behalf of Gershon Joseph <>

Date: Sunday, May 23, 2021 at 3:33 AM

To: Robert Anderson <>, "" <>

Subject: [dita] Re: Follow-up on longquoteref

 

[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 

Direct: +972 (54) 658-3887| Email:  |

www.precisioncontent.com

 

 

Unlock the Knowledge in Your Enterpriseâ

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
 If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Please
 notify us by return email if you have received this email in error. Â2021, Precision Content Authoring Solutions Inc, Toronto, Ontario, Canada

 

 

From:
 <> on behalf of Robert Anderson <>

Date: Friday, 21 May 2021 at 19:51

To:  <>

Subject: [dita] Follow-up on longquoteref

As noted at the TC week, our overlapping capabilities with <lq> and <longquoteref> are more complicated than I thought.

 

The current status is:

The <lq> element has linking attributes (href, scope, format, type), although type has an alternate definition, which no longer really makes sense. It also has the reftitle attribute to specify the title of the source of the quote.

The <longquoteref> element lets you specify a link within the content, but is empty; it cannot specify the title. If associated with a key, then it could be associated with a title, but the grammar does not let you specify one.

<lq> also allows <xref>, so with child elements it can specify normal links + a link to the source (minus title).

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:

Ignore it and we have this confusing overlap.

Allow text / phrases in the longquote ref, so that it can specify a title, and remove the linking / reftitle attributes from <lq>. It's still a bit odd that we can specify both <xref> and <longquoteref>, but it has a clear purpose
 and we only have one way to indicate the source of the quote.

Remove the attributes andâ the longquoteref. If you want to specify the source of the quote, you have to use <xref>. If you want special styling, you probably use @outputclass and customize styling.

Remove the linking attributes and the element, but add @keyref to <lq>. This makes the block long quote sort of like keyword, phrase, and other non-linking elements that
canâ link if you set up a key. This would also be a way to specify a title (use keyref, with or without a link).

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