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: Another legacy attribute to remove? mapkeyref

Hi Robert,


I never had the need to use it. I support its removal from the 2.0 spec.





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. ©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:




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?




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