dita — archive

ditabase

From: Tom Magliery <[email protected]>
To: [email protected]
Date: Thu, 19 Apr 2018 19:08:00 -0000

I think it would be nice not to see the word "deprecated" anywhere in the DITA 2.0 specification. mag On Thu, Apr 19, 2018 at 11:55 AM, Jim Tivy < [email protected] > wrote: Agreed Chris On the idea of referencing a list of topics from a map - seems using a submap would be a best practice? A number of tools produce flat submaps from searches based on metadata etc. Jim On 2018-04-19 5:55 AM, Chris Nitchie wrote: All four of these use cases can be accomplished with <topic> as the root element. You don’t need <dita>. This is why I toyed with the idea of removing <dita> a few weeks ago. The use-case that turned me around was that of referencing a ditabase from a map without a fragment identifier, which should result in all those topics appearing in output as siblings of each other. You can’t do that with <topic> without adding a layer of hierarchy. Chris From: <[email protected]> on behalf of Kristen James Eberlein <[email protected]> Date: Wednesday, April 18, 2018 at 8:59 PM To: "[email protected]" <[email protected]> Subject: Re: [dita] ditabase There are several compelling use cases: Aggregating small topics, such as message topics Used for conref library files 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. Being useful for migrating content (WARNING: If the content stays in ditabase, that's ... icky.) I think removing ditabase would be very intrusive and disruptive. 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/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