[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
|
Considering the fact that: ·
New DITA (more or less compliant) tools and
products are appearing regularly ·
New versions of existing tools are coming out
each month (sometimes several each month) …the sheer workload involved in maintaining a fully
documented DITA scorecard on each would be quite overwhelming. Accordingly, I strongly support the idea of this TC creating
a structured DITA checklist/scorecard. This checklist should be made available
(on dita.xml.org) for anyone – and it could be used by companies to
structure their discussions with vendors as well as deciding on what level of
compliance they need – or in what area they should focus. Steffen Frederiksen -----Original Message----- +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 --------------------------------------------------------------------- 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]