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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-adoption message

[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]