Thanks for the background history. I think @lockmeta is a great
candidate for removal in DITA 2.0.
What do other voting members of the DITA TC think?
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)
On 7/15/2019 4:22 PM, Robert D Anderson
wrote:
I've always found @lockmeta to be a bit unclear
and have largely implemented it only on a "pretty sure I know
what was intended" basis. It's probably something we should
consider either removing in 2.0, or pretty heavily redefining.
If you look back through the history of the
attribute ...
In DITA 1.0 the attribute was declared in the
grammar, but listed as undefined in the spec: http://docs.oasis-open.org/dita/v1.0/langspec/topicmeta.html
In DITA 1.1 it was defined but pretty loosely: http://docs.oasis-open.org/dita/v1.1/OS/langspec/langref/topicmeta.html
The general goal, as I remember / understood it,
was based on a mental model that closely mapped how DITA Open
Toolkit processing worked. When you publish something, you had
to reconcile which metadata wins (that in the topic, or that
in the map). Generally something in the map supplements /
overrides what's in the topic, and this was a way to say "Even
if something is hard coded in the topic, apply the metadata
I've got here". The whole language around "replacing" only
makes sense in that toolkit context where you actually have a
file where things are added / removed / combined.
DITA 1.2 and 1.3 were slightly clearly in
describing what "yes" means -- "If you set this to yes, it
means your metadata is locked, and you can't ignore it".
I do think this whole idea of locked metadata is
less relevant today than it was when originally imagined. As
you can see in that original language, the premise was really
based around a DITA-OT model (where metadata is "replaced"
during a build).
More recently, in DITA 1.2 and especially in DITA
1.3, we have treated metadata in the map as something
associated with that specific context. You can do something
with it (or not) based on that context, but we don't mandate
whether or not a publication process would "replace" that
context-based metadata with something else.
So yeah - it went from declared-but-undefined in
1.0, to loosely defined, to ... still loosely defined even in
1.3. I'm not sure I've seen it used in real docs, and given
how hard it is to talk about in the abstract, I'm not sure
it's necessary.
For the second part of your question -- the
conflict that navigation titles comes out of how those turned
from an attribute (in DITA 1.0 / 1.1) into an element in DITA
1.2. These were clearly not meant to be related in DITA 1.0 --
titles were controlled by @locktitle on the topic reference,
while metadata was meant to be controlled by @lockmeta. It
just happened that <navtitle> was added later into
<topicmeta>, which added a bit of confusion. However,
the 1.3 specification still clearly describes how titles are
controlled by @locktitle (rather than @lockmeta).
Robert D. Anderson
DITA-OT lead and Co-editor DITA 1.3
specification
Marketing Services Center |
Kristen James Eberlein ---07/11/2019
01:18:56 PM---This is an attribute that we might want to
consider for changes in DITA 2.0. Here what the DITA 1.3
From: Kristen
James Eberlein <kris@eberleinconsulting.com>
To: DITA
TC <dita@lists.oasis-open.org>
Date: 07/11/2019
01:18 PM
Subject: [EXTERNAL]
[dita] @lockmeta on <topicmeta>
Sent by: <dita@lists.oasis-open.org>
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)
--------------------------------------------------------------------- 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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|