[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
+1 to everything Troy said! I've been there as well ;-) Mary > -----Original Message----- > From: Troy Klukewich [mailto:troy.klukewich@oracle.com] > Sent: Monday, August 18, 2008 7:59 PM > To: dita-adoption@lists.oasis-open.org > Subject: RE: [dita-adoption] dita.xml.org resource about DITA tools > > Hi Mary: > > I was wondering about OASIS liability, but figured someone who knows > better would jump in if needed. :-) > > I think the checklist idea would at minimum be useful for us internally > for marshalling discussions with vendors. It would also probably help > us define what at minimum is required for a successful implementation, > at least from a technical perspective, which is important. (Change > management is an additional critical area that I will save for later.) > > There are an increasing number of tools out there that claim they "do" > DITA, which adds to the confusion in the marketplace. Some do a lot > more than others. Call me skeptical, but if I discover they don't read > and write native DITA files, aren't remotely current, or do not support > specialization, I write them off my own personal list of adoption tools > for consideration. (Though there is probably a special case for > everything.) > > I do like the idea of defining or garnering a minimum test set, at > least for our own uses. I am currently involved in a series of DITA > implementations for a number of products and was involved in a number > of non-DITA, XML-based structured documentation projects at a previous > company. > > In each case, we came up with testing criteria as part of our XML > adoption plan. We tested a number of tools and were quite surprised at > the results. We avoided a lot of downstream pain and surprises. > > The adoption group can probably help with a set of adoption best > practices to help guide and protect the marketplace. If those practices > weed out the pretenders, or help vendors identify what they really need > to support, we'll be helping the marketplace. > > Troy > > > -----Original Message----- > From: Mary McRae [mailto:marypmcrae@gmail.com]On Behalf Of Mary McRae > Sent: Monday, August 18, 2008 11:48 AM > To: 'David J. B. Hollis'; 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 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 > > > -----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 > > > --------------------------------------------------------------------- > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]