dita — archive

ditabase

From: Jim Tivy <[email protected]>
To: [email protected]
Date: Thu, 19 Apr 2018 18:53:00 -0000

Hi Kris I agree your use cases are compelling but is ditabase the only way to accomplish those compelling use cases. And is ditabase the best practice? I guess I would prefer to have consensus on this (or agreement to not agree:) whether it gets removed or not is a second question. I do not see any mention in the spec that it is deprecated - seems we might have to do that first if we agreed. For existing tool vendors and existing users it is likely more of an annoyance if anything as they support it - bunch of special use code if you make use of the dita class attribute. But for new tool vendors and new users it may be more annoying. On 2018-04-18 5:59 PM, Kristen James Eberlein wrote: There are several compelling use cases: Aggregating small topics, such as message topics - can be done with a nested topic. Used for conref library files - often no need for multiple topics for conref libraries so a single topic would suffice or use nested topics if need be. Creating only one topic shell (assuming that all topic types need the same domains), and using the CMS templates to specify the topic type. IXIASOFT does this by default. Not sure I fully understand the end user use case here. Being useful for migrating content (WARNING: If the content stays in ditabase, that's ... icky.) I assume you mean a package like a zip would be? I would think external packaging is best done with zip of individual files and relative links - if I understand your point. I think removing ditabase would be very intrusive and disruptive. I agree, we would need a simple migration path. Or we leave it in and we agree it is deprecated. Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 622-1501; kriseberlein (skype) On 4/18/2018 8:32 PM, Eliot Kimber wrote: I can’t agree with the assertion that ditabase is obsolete—it has a necessary utility—Robert provided some compelling use cases from IBM (e.g., 100s of small message topics organized together in a single <dita> document). I’ve definitely seen the ditabase document type abused as a way to avoid creating local shells because it allows unrestricted topic type nesting—I find that distasteful but it’s not exactly wrong, even if it is a big misguided. Cheers, E. -- Eliot Kimber http://contrext.com From: <[email protected]> on behalf of Magliery Tom <[email protected]> Date: Wednesday, April 18, 2018 at 6:51 PM To: Jim Tivy <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [dita] ditabase FWIW that content is not directly from oXygen; it is from Tony Self's book The DITA Style Guide (2011), republished in oXygen docs (by arrangement). mag On Wed, Apr 18, 2018 at 4:41 PM, Jim Tivy < [email protected] > wrote: https://www.oxygenxml.com/dita/styleguide/webhelp-feedback/Artefact/Topics_and_Information_Types/c_Using_Ditabase.html Can we get rid of <dita> for DITA 2.0. We just had another issue here and with Oxygen posting the above we are wondering how long the ecology of tools will continue support for <dita>. I realize this was discussed a few weeks back and it seemed there was support for <dita> removal. What would be the easiest upgrade for people with <dita> files? There was some mention of needing a title but users could have an empty title or descriptive title at their option. Jim --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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