Hi Robert,
I never had the need to use it. I support its removal from the 2.0 spec.
Gershon
Gershon Joseph | Senior Information Architect | Precision Content
Direct: +972 (54) 658-3887| Email: gershon@precisioncontent.com |
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. ©2020,
Precision Content Authoring Solutions Inc, Toronto,
Ontario, Canada
From:
dita@lists.oasis-open.org <dita@lists.oasis-open.org>
Date: Friday, 4 December 2020 at 23:18
To: dita@lists.oasis-open.org <dita@lists.oasis-open.org>
Subject: [dita] Another legacy attribute to remove? mapkeyref
Hi everyone,
The “mapkeyref” attribute is available on three elements: <metadata>, <linklist>, and <linkpool>. It’s the last one defined on this page:
Specifically:
Identifies the map, if any, from which the contained links or metadata are derived. This value might be automatically generated by a process that creates the links or metadata based on map context, as a
way to identify which map the material came from. If the <linklist>, or
<linkpool>, or metadata is manually created by an author, there is no need to use this attribute. Note that this attribute is not related to
the @keyref attribute, and is not used for key based processing.
This attribute is really there as a processing attribute – much like xtrf and xtrc, which we already removed from DITA 2.0. The original purpose was based on tool chains like DITA-OT, that go through sequential
processing steps, one of which generates these elements in a topic, based on the map; the attribute identifies what map those generated elements came from.
Much like xtrf and xtrc, that use case alone is not a good reason to define the attribute in the specification. Also like xtrf and xtrc, removing it would have no impact on anyone using it in that processing
context. It’s also a bit grating to have an attribute named “mapkeyref” that does not use keys, and has to explicitly deny any relationship to keyref.
Is anyone making use of this attribute in source files, or is this another candidate for cleanup?
Thanks,
Robert