RE: Tool comparison (Was: Alternative for DITA Help Technologies Guide)

["Marc Speyer" <mspeyer@stilo.com>]

Hi all,

Thanks for the encouraging words on the suggestion for an alternative for the DITA Help Technologies Guide (which is somewhat misleading because what is suggested is really something different). The idea behind this is to help the DITA adopters to select the proper software tools. I agree with Alex that we should stay away from the "actual" software tool comparison because this is what will get us into the same risky position as was perceived with the Help Technologies Guide. What I meant is a selection tool that people can use to figure out what is important to achieve their goals (very close to what Don suggested). The selection would help people to:
1. understand which functional areas are relevant for DITA
2. decide which of these functional areas could be important for them 
3. validate conformance of software tools by means of a test set

It would be up to the DITA adopter if they want to go through a package selection process, e.g. by extracting and sending out questionnaires or something similar to vendors. I would leave it to bloggers, vendor and other sites if they want to maintain a tool ranking based on the selection tool we provide. Most rankings are just a snapshot view anyway with some (unknown) prioritization playing in the background.

So how would people use this selection tool?

Let's take for example a functional area like PDF printing. Using the OT a very important component is the rendering engine, but what if the rendering engine does not support MathML or EPS and some of your content happens to be in this format. And if you are using MathML you need to think of a way to create it, to maintain it, etc. Is it important that the author sees the equation while editing the text of a topic? If the MathML is stored in a CMS do you want to preview it? Should the CMS also create a thumbnail for it? It is quite easy to come up with a lot of functional requirements and most people would say yes to all of them, but there is of course a price to pay for having all of this. The selection tool should provide a way for people to prioritize requirements, for example using the familiar prioritization MosCoW method (Must, Should, Could, Wont). There are often alternatives when a requirement is not met, for example again the MathML issue could be addressed by adding to the pipeline processing a step to convert MathML into a bitmap or SVG. This may introduce some challenges for software packages that have integrated the toolkit and the DITA adopter should be aware of this. Again using the case of MathML and PDF the selection could look like this:

-- start of example ---
Main goal: PDF printing
...
Requirement: MathML support
  Why this requirement?
  When is it important?

  MathML in files referenced from topics
     Standard OT processing => Rendering engine must support MathML
     OT + MathML conversion => list of software libraries + customization steps (pipeline processing)

  MathML embedded in topics
     ...

Sample test set of MathML + expected output
...

Main goal: Online Help
...
-- end of example ---

Of course the above should all be organized in an easy to read way (e.g. using tables for example).

I hope this clarifies things a bit better. 

Regards,

Marc Y. Speyer
Stilo International plc
www.stilo.com

> -----Original Message-----
> From: Scott Prentice [mailto:sp@leximation.com]
> Sent: Wednesday, April 08, 2009 7:12 PM
> To: alexm@writepoint.com
> Cc: mspeyer@stilo.com; dita-adoption@lists.oasis-open.org
> Subject: Tool comparison (Was: Alternative for DITA Help Technologies
> Guide)
> 
> I think it would be very useful to provide a comprehensive list of
> features that a DITA authoring tool might offer and how the tools stack
> up. This wouldn't likely be a yes/no sort of thing but probably more of
> a rating from 0 to 5 since there will always be shades of gray. The
> feature list might be maintained by this committee, but the compliance
> level and rationale might be provided by the vendors themselves (with
> review from the committee). If a vendor wanted a feature added to the
> list they would need to get approval from the committee.
> 
> This would not only be a benefit to end users who are looking for a tool
> with specific features, but also would help to raise the bar for the
> vendors themselves by seeing the features that are lacking in their
> tools. This would be difficult to do as a wiki .. it would quickly get
> out of hand .. and is more suited to a database-supported web app. I've
> considered putting this type of thing together myself, but it would be
> best to be sponsored and managed by OASIS to ensure it is unbiased as
> possible.
> 
> Just a thought.
> 
> Cheers,
> 
> ...scott
> 
> Scott Prentice
> Leximation, Inc.
> www.leximation.com
> +1.415.485.1892
> 
> 
> 
> alexm@writepoint.com wrote:
> > Hi Marc,
> >
> > I agree that providing some tangible criteria that would help DITA
> adopters
> > pick up tools they need is a good idea. The question that we'll have to
> > answer, though, is what a DITA adopter should expect in the end. Should
> we
> > bring him or her - through iterative exploration of the needs - to one
> > single tool or should it be a list of tools that can potentially fit the
> > needs? If the former option, then we put ourselves in a pretty risky
> > position of being affiliated with a specific tool (who can ensure that we
> > used objective criteria?). If the latter option, will it useful and
> > practical enough?
> >
> > Or should the criteria we give should be a roadmap that provides general
> > recommendations on the selection process? Or should it take a form of
> > detailed case studies that explain how and why specific companies with
> > their specific needs choose a specific tool?
> >
> > In any event, I think you raised a very interesting and important issue.
> I
> > would be interested in joining you and other interested TC members to
> work
> > on criteria and finding solutions for helping DITA adopters select tools.
> >
> >
> > What other members think about how we can move forward?
> >
> > Alex
> >
> > --
> > Alex Masycheff
> > Senior XML Project Manager, WritePoint Ltd.
> > Member, OASIS DITA Adoption Technical Committee
> >
> > Website: http://www.writepoint.com
> > Blog: http://www.writepoint.com/blog
> > Mobile: +972 50 274 4330
> >
> >