Meant to send to list ...
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)
-------- Forwarded Message --------
Thanks, Robert.
I am curious; do we have any knowledge of how commonly
properties tables are used? I confess to encouraging users to
just use simple tables, for ease of reuse in other topic types.
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)
On 4/22/2019 4:54 PM, Robert D
Anderson wrote:
I took this one on a while ago because it
seemed pretty simple and a nice usability thing to add to
DITA 2.0:
https://github.com/oasis-tcs/dita/issues/123
Of course nothing is as easy as planned, so I'm
looking for input from the broader TC before I write it up.
The problem today: the properties element is
available today, but only as a child of the reference body
(refbody) element. Ideally, it should be usable other places
in the reference topic, such as in the reference syntax
section (refsyn element) or in section itself.
Looking for input on the cost/benefit of two
options:
- Option 1: just add it to the <refsyn>
model. In sections meant to describe reference syntax, you
can use the properties table. This is really a trivial
update, but it still means if you try to add properties
tables into a normal section it won't work. The only real
upside is, absolutely no issues with migration / backwards
compatibility.
- Option 2: pull the definition of the
property table element out of the Reference module and
make it a domain, then add it back into the reference
topic model. This really makes it a domain, and lets you
use it anywhere in a reference topic. The down side is, it
requires a migration of any configured shell for reference
topics. Property tables will be invalid in reference
topics that do not use the default OASIS shell, until the
configuration is updated to add the domain. It's a pretty
straightforward update, but not easily automated because
configured shells can follow a lot of different patterns.
- Option 2a: We could make a standalone
domain for the property tables (nine elements total,
the table container and 8 child elements). This would
basically be a reference domain, only used in
reference topics.
- Option 2b: We could keep defining
property tables inside the reference module, remove it
from the reference body model, and declare it in the
shell as if it were a domain. This would probably be
easier to maintain but would be a quirky way of making
a "domain" element.
Thoughts? I really only took this on because
"hey, easy thing I can push forward", and I don't have a
strong preference for one option over another.
Robert D. Anderson
DITA-OT lead and Co-editor DITA 1.3
specification
Marketing Services Center |
|