OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] LwDITA markup inconsistency, missing keyref on highlight elements

I agree with Eliot and vote to add @keyref to these elements.



Gershon Joseph | Senior Information Architect | Precision Content 
Direct: +972 (54) 658-3887| Email: gershon@precisioncontent.com | www.precisioncontent.com


A picture containing drawing, food, plate

Description automatically generated


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: dita@lists.oasis-open.org <dita@lists.oasis-open.org> on behalf of Eliot Kimber <ekimber@contrext.com>
Date: Monday, 24 May 2021 at 23:50
To: dita@lists.oasis-open.org <dita@lists.oasis-open.org>
Subject: Re: [dita] LwDITA markup inconsistency, missing keyref on highlight elements

I would definitely vote to allow keyref: more consistency and less surprise.

It's a pretty easy constraint to impose if anyone cares that much.



Eliot Kimber

ïOn 5/24/21, 1:57 PM, "Robert Anderson" <dita@lists.oasis-open.org on behalf of robert.dan.anderson@oracle.com> wrote:

    Hi all,

    Perhaps I should stop digging through DTDs and RNGs, but while doing so I've found another inconsistency. This one is actually an issue for LwDITA rather than for the base spec, but addressing it likely impacts the base spec.

    In LwDITA, all phrase-level reuse is done with the keyref attribute, rather than conref, as part of an effort to make sure there is only one way to reuse any type of phrase. This means that the LwDITA modules expect keyref to be on highlight elements such as
     <b>, <i>, and <u>, as well as the upcoming elements <em> and <strong>. The %variable-content; entity in here adds keyref to five highlight elements:

    The problem is that in the base DITA vocabulary, none of these elements allow keyref, so specifying it on LwDITA highlight phrases means that those elements are no longer a valid subset of DITA. It's not there in

    DITA 1.3 grammar <https://github.com/oasis-tcs/dita/blob/master/doctypes/rng/base/rng/highlightDomain.rng#L105> and it's still not there in the
    DITA 2.0 definition <https://github.com/oasis-tcs/dita/blob/DITA-2.0/doctypes/rng/base/highlightDomain.rng#L114>.

    Digging deep into memory, the only reason I can think of that it was left off was to nudge authors into using more semantic elements for reuse. These elements all specialize from <ph> which does allow key references, so it would be legal to add it. Given the
     LwDITA use case, it seems like at this point we should probably let these elements use keyref, unless there is a compelling reason to keep it off. If we do decide to keep it off, that means a fair bit of churn in how reuse is managed in the context of LwDITA.


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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]