OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Fwd: Re: [dita] Proposal for properties table


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 --------
Subject: Re: [dita] Proposal for properties table
Date: Tue, 23 Apr 2019 08:09:22 -0400
From: Kristen James Eberlein <kris@eberleinconsulting.com>
To: Robert D Anderson <robander@us.ibm.com>


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

E-mail: robander@us.ibm.com

11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA
IBM




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]