|
If I look at the DITA 1.3 specification, it looks like the <chapter> element, a specialization of <topicref> specifically intended to refer to topics (as well as maps) doesn't allow @lockmeta.
That seems like one can of worms; should specializations of topicref allow @lockmeta?
Another can of worms might be that the operation of the attribute seems precisely backwards; do the default thing and override the topic metadata unless the value for the lock attribute on the topic reference is "no". I'm sure I'm just not looking at it from
the correct perspective, but this seems actively confusing. (Or the original name of the attribute was @permit-overrides or similar.)
Yet another can of worms would be granularity; right now, @lockmeta is everything-or-nothing, but everything isn't defined. It's not difficult to imagine use cases for more granularity than that.
And the last obvious can of worms is the one noted as 2 originally; how does @lockmeta interact with other processing control attributes?
I think it might be simpler to view things as content (we expect to present this to the audience in the main flow of text), alternative text (this can be substituted for content), and metadata (we store this distinctly from the content and don't expect that
it will be rendered as part of the main flow of text). So <navtitle> , <searchtitle>, and <booktitlealt> (for example) are alternative text. Making a distinction about alternative text changes the question from "is <navtitle> metadata?" to "do we want a
switch to treat alternative text elements as metadata during processing?" which I think is easier to answer. (I'd answer yes.)
Graydon Saunders | Publishing Solutions Developer | Precision
Content
Direct: +1 (647)265-8500
x106| Email: graydon@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. ©2019, Precision Content Authoring Solutions Inc, Mississauga, Ontario, Canada
From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> on behalf of Kristen James Eberlein <kris@eberleinconsulting.com>
Sent: 11 July 2019 14:18
To: DITA TC
Subject: [dita] @lockmeta on <topicmeta>
This is an attribute that we might want to consider for changes in DITA 2.0. Here what the DITA 1.3 spec says:
@lockmeta
By default, metadata in the map supplements or overrides metadata that is specified at the topic level, unless the @lockmeta attribute of the <topicmeta>element
is set to "no". Allowable values are "yes", "no", and Using
the -dita-use-conref-target value.
A couple of things:
- I'm not sure that we specify anywhere what our expectations for processors are about the differences between supplementing and overriding metadata.
- The DITA 1.3 element reference topic for <topicmeta> is ambiguous, since it implies that navigation titles are metadata, but whether navigation titles specified in maps are used depends on whether @locktitle is set to "yes". (Does @lockmeta also have an
effect on navigation titles?)
--
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)
|