[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita-adoption] dita.xml.org resource about DITA tools
Hi, All One obvious question I forgot concerns cross platform capabilities. Pretty obvious, really, as I'm a Mac user! To address Mary's concerns, we could possiibly adopt something similar to W3C's self-certification type model. A series of content and integration tests, perhaps? David > Hi everyone, > > I think it's a great idea to list tools and have a checklist > according to > the list below, but the world of conformance testing and > certification is > not only complex, it's littered with potential liability. What does > it mean > to be conformant to the DITA specification? Are there conformance > clauses in > the current OASIS Standard? Has anyone built test suites that > correspond to > those conformance clauses? > > OASIS now requires conformance statements in all of its > specifications; once > that's done, some group may want to take up the challenge of writing > testing > guidelines and test suites. OASIS does not currently plan to get > into the > certification business; there are companies who do that and their > business > model is appropriately structured. That doesn't mean that OASIS > couldn't > partner with one or more certification organizations, but > unfortunately it's > much more complicated than first meets the eye. > > Getting back to the checklist idea for each product, it might be a > worthwhile task for the TC to reach out to each of the product > vendors and > talk with them about perceived deficiencies, interoperability > problems and > the like. My guess is that you'd get a lot of good feedback that > should be > directed back to the DITA TC - why is it that they did something in > the > non-standard way? What was the user community telling them that they > needed? > What other approaches might have been possible that would not have > deviated > from the specification? Is it a matter of writing "best practices" > guides? > Was it a misunderstanding in how the specification should be > interpreted? Is > the standard unclear? > > I think there's some great ideas that can be gleaned from this > thread - all > of which could have a positive focus and work to improve both the > specification and the available tools and thereby grow DITA adoption. > > Regards, > > Mary > > I like your list of questions, David. I'd add a few other ones: > > * Does the tool come with effective documentation that makes it easy > for the end user to get up and running? > * If the tool incorporates the DITA Open Toolkit, can a user run > transformations without a gazillion configuration changes? > > (I recently used a trial-version of a major DITA authoring tool, > but never managed to get the incorporated version of the Toolkit > to work. My own stand-alone version of the Toolkit worked fine.) > > Troy, thanks so much for starting this thread about tool standards. > > Kris > >> -----Original Message----- >> From: David J. B. Hollis [mailto:dhollis@AandOConsultancy.ltd.uk] >> Sent: Monday, August 18, 2008 2:12 PM >> To: troy.klukewich@oracle.com >> Cc: Kristen James Eberlein; dita-adoption@lists.oasis-open.org >> Subject: Re: [dita-adoption] dita.xml.org resource about DITA tools >> >> Hi >> >> My first thoughts were that Bob Doyle has done a pretty good job on a >> comprehensive tool round up, and how/why should we try to duplicate >> this effort? My main criticism, however, would be that Bob refrains >> from being at all critical about any tool's suitability for use with >> DITA. This can be contrasted with Eliot Kimber's 'Dr. Macro' blog >> concerning tools: 'All Tools Suck!' http://drmacros-xml- >> rants.blogspot.com >> >> If this could somehow be grafted into the dita.xml.org wiki, then >> there is the opportunity for anyone to add their comments about a >> tool's suitability, or otherwise, for use with DITA. To that end, the >> TC becomes a channel for marshalling resources & appropriate >> comments. >> >> However, I do like Troy's idea of setting some form of standard which >> a tool should achieve. This is surely what a Standards Body should be >> about? >> >> Here's some initial suggestions: >> >> 1. Which version(s) of the DTD/Schema are supported? >> >> 2. Does the tool use the Open Toolkit at all, and how has it been >> modified? >> >> 3. If the Open Toolkit is incorporated, which version is provided? >> >> 4. If the Open Toolkit is incorporated, is it available for use by an >> external publishing workflow? >> >> 5. Does the tool support XML Catalogs? >> >> 6. Does the tool support Specialisations? >> >> 7. Does the tool support content, Map & Bookmap editing? >> >> 8. Does the tool support 'on-the-fly' processing to easily see how >> the >> current Topic may be rendered? >> >> 9. Does the tool offer any CMS integration? >> >> >> Many of the above would need a 0-10 scale, or similar, rather than a >> simplistic yes/no. >> >> OK, a Tool Standard and Review Process is not going to be achieved >> overnight, but the wiki approach could suffice in the interim. >> >> Hmmm, 'Tool Standard' needs to be added to 'Opportunities'! ;-) >> >> David >> >> >>> Hi: >>> >>> <quote> >>> I wonder if the Adoption Committee has the resources to do a regular >>> analysis of tools and how well they support DITA. >>> </quote> >>> >>> I think this is a great idea. As there are an increasing number of >>> tools, and to keep our resource commitments under control, I have a >>> variation on the idea of a regular tool review. >>> >>> Maybe we could create a DITA Adoption "Gold Circle" for tools that >>> meet a hard core, minimal set of objective requirements. The tools >>> would need to meet the requirements in order to be considered the >>> top tools in use for adoption, tools that we would recommend given >>> our real-world criteria. >>> >>> We could perform a minimal set of reviews of the current top tools >>> and assign an initial "badge of approval" for the tools that pass. >>> After that, we can encourage tool vendors to apply. Otherwise, we'll >>> be performing a large set of regular reviews for tools that probably >>> don't meet the requirements. >>> >>> In other words, going forward, if a tool vendor wants our badge of >>> approval, they need to apply, after reviewing our publicly posted >>> requirements. If they don't meet the requirements, don't apply. >>> >>> I would think that vendors could get some marketing mileage out of >>> our seal of approval. Plus, we would gain more visibility as a body >>> dedicated to easing DITA adoption, a proverbial win-win. >>> >>> There's more to discuss, so maybe we can migrate this discussion to >>> the wiki, but I have to run. :-) >>> >>> Troy Klukewich >>> Information Architect >>> Oracle >>> >>> -----Original Message----- >>> From: Kristen James Eberlein [mailto:keberlein@pobox.com] >>> Sent: Monday, August 18, 2008 9:04 AM >>> To: dita-adoption@lists.oasis-open.org >>> Subject: [dita-adoption] dita.xml.org resource about DITA tools >>> >>> >>> http://dita.xml.org/resource/dita-tools-from-a-to-z >>> >>> I wonder if the Adoption Committee has the resources to do a regular >>> analysis of tools and how well they support DITA. As someone >>> mentioned, >>> it might help push vendors to do more complete implementations. >>> >>> Kris >>> >>> Kristen James Eberlein >> >> --------------------------------------------------------------------- >> 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]