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

Not using it that I'm aware of. I'd say it's a candidate for cleanup, as long as the toolkit no longer relies on it.




From: <dita@lists.oasis-open.org> on behalf of Robert Anderson <robert.dan.anderson@oracle.com>
Date: Friday, December 4, 2020 at 2:18 PM
To: "dita@lists.oasis-open.org" <dita@lists.oasis-open.org>
Subject: [dita] Another legacy attribute to remove? mapkeyref


[External Email]


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]