Re: [dita] (Resend and update) Should the map <linktext> element be specialized from <titlealt>?

[Eliot Kimber <ekimber@contrext.com>]

Making linktext a specialization of titlealt makes sense to me--I agree that the semantic seems consistent.

Cheers,

E.

--
Eliot Kimber
http://contrext.com
 

ïOn 11/25/19, 11:27 AM, "Chris Nitchie" <dita@lists.oasis-open.org on behalf of chris.nitchie@oberontech.com> wrote:

    This is a re-send of something I sent to the list this morning. Something about it got it flagged as junk mail for me, and I suspect others. I've reformatted it as plain text in the hopes it works better. There are also some refinements to my initial message, so in the event that you saw the earlier one, disregard it in favor of this one.
    
    TL;DR: I'd like to expand the titlealts improvement proposal such that map/linktext is refactored as an alternate title, and is renamed <linktitle> to avoid conflicting with <linktext> in topics, and so that it fits more neatly with <navtitle> and <searchtitle>.
    
    I'm (finally!) working on my Stage 3 proposal for the titlealts improvements and I've hit an unexpected snag. The plan, as of Stage 2, is to move <navtitle> and <searchtitle> into their own 'alternative titles' domain, specialized from the new base <titlealt> element. The problem is the content model of <topicmeta>, which currently includes:
    
            <optional>
              <ref name="navtitle"/>
            </optional>
            <optional>
              <ref name="linktext"/>
            </optional>
            <optional>
              <ref name="searchtitle"/>
            </optional>
    
    Note that <linktext> is nestled there in between <navtitle> and <searchtitle>, which means that simply pulling them out and replacing them with <titlealt> won't work:
    
            <zeroOrMore>
              <ref name="titlealt"/>
            </zeroOrMore>
            <optional>
              <ref name="linktext"/>
            </optional>
    
    Now, any existing document that contains <searchtitle> after <linktext> will be invalid, because that ordering - which used to be required - is no longer allowed.
    
    I see three solutions to this.
    
    1) Allow zero-or-more <titlealt> elements both before and after <linktext>.
    2) Force users to reorder their <topicmeta> as part of migration to 2.0 when they have both <searchtitle> and <linktext> (which will likely be a relatively small subset of cases).
    3) Make <linktext> a specialization of <titlealt>, along with <navtitle> and <searchtitle>, and rename it <linktitle>.
    
    I prefer (3). The <linktext> element specifies text to use instead of the title for links, so semantically it would make sense. Additionally, the <linktext> element's placement in the current grammar suggests that it is of a kind with the other two. However, by moving this element out into the alternate titles domain, which is included in both maps and topics, it would conflict with the existing <linktext> element used inside <link>, so it would need to be renamed. I propose <linktitle>. This new element would appear in <titlealts> in topics as well as inside <topicmeta> on maps, which adds a new processing requirement to implementors (that they check the topic as well as the map for link titles). However, I'm inclined to think that adding this capability to standalone topics probably has some value, so I think that's OK.
    
    None of this was included in the Stage 2 proposal, so I'd like to know what others think.
    
    Thanks,
    
    Chris
    
    
    The content of this email and any attached files are intended for the recipient specified in this message only. It may contain information that is confidential, proprietary, privileged, and/or exempt from disclosure under applicable law. It is strictly forbidden to share any part of this message with any third party or rely on any of its contents, without the written consent of the sender. If you received this message by mistake, please reply to this message and follow with deletion of the original message, any copies and all attachments, so that Oberon Technologies can ensure such a mistake does not occur in the future.