Am 17.06.10 15:11, schrieb Mojca Miklavec:
On Wed, Jun 16, 2010 at 19:56, Wolfgang Schuster
<schuster.wolfg...@googlemail.com> wrote:
Hi,
i plan to update cont-en.xml with changes in mkiv (new keys and commands)
but i'm unsure if it's good to mix mkii and mkiv. I think it's to make a
separate definition file for mkiv which contains the extra keys for the
commands (e.g. sectionsegments for \setuphead) and use the current one for
mkii only.
My opinion (though at the end you may do it either way): I would put a
special key to either each command or each option that would clarify
"mkii only" or "mkiv only" or "both". If command is completely
different, for example
\usetypescript[name][ec] in mkii vs. \usetypescript[name] in mkiv
one could define two commands and label one as "mkii only" and the
second one as "mkiv only".
There might be also another thing worth keeping in mind. Some commands
may be valid, but useless in mkiv. It might make sense to label those
as such.
Even though the fact that "mkii is frozen" might be true, most of
valid options are still missing in those xml files.
Again: I would keep a single file with a new key that would specify in
"which mark" commands works and/or makes sense. That way it would be a
tiny bit easier to maintain both versions synchronized (assume that
you will want to document a new command that's also present in MKII -
are you going to remember that you also need to update MKII; and then
one will see a command in MKIV, but will have no idea whether the
absence in MKII means that somebody forgot that command or that it's
simply not present/working there).
But since you are planning to work on it, it's up to you to decide.
That was only my opinion.
For the start i'll go only through the mkiv files and use a separate
file for them,
maybe later i can compare the mkiv with the mkii options and use hans
approach
because tagging each key and command is a lot of work.
Wolfgang
_______________________________________________
dev-context mailing list
dev-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-context
