> When you convert a DITA topic, {{document-date}} is always the current date
> (that is, always today).
OK, thanks for clarifying that. Perhaps another argument in support of a tight
link between a topic and its conversion parameters, so that generating output
from topic A always pulls in the same explicit header/footer information?
I feel there could be arguments in favour of reading <critdates> at topic level
when creating output from a single topic: I manage quite a few procedures as
standalone topics, and it makes sense to have access to the <critdates>
information. Also, surely one of the major benefits of splitting monolithic
documents into topics is that separate topics can evolve at different speeds?
so I already have at least one .ditamap where the meta-data at map level
identifies the last time the structure of the map was changed while each topic
has its own <critdates>.
N
*********************************************************************************************
Worldline SA/NV - Chaussee de Haecht 1442 Haachtsesteenweg
- 1130 Brussels - Belgium
RPM-RPR Bruxelles-Brussel - TVA-BTW BE 0418.547.872
Bankrekening-Compte Bancaire-Bank Account 310-0269424-44
BIC BBRUBEBB - IBAN BE55 3100 2694 2444
"The information contained in this e-mail and any attachment there to be
confidential and may contain information which is protected by intellectual
property rights.
This information is intended for the exclusive use of the recipient(s) named
above.
This e-mail does not constitute any binding relationship or offer toward any of
the addressees.
If you are not one of the addressees , one of their employees or a proxy holder
entitled to hand over this message to the addressee(s), any use of the
information contained herein (e.g. reproduction, divulgation, communication or
distribution,...) is prohibited.
If you have received this message in error, please notify the sender and
destroy it immediately after.
The integrity and security of this message cannot be guaranteed and it may be
subject to data corruption, interception and unauthorized amendment, for which
we accept no liability."
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
