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


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [dita] RE: [dita-adoption] Re: [dita] who complains aboutcomplexity of DITA?

I'm largely in violent agreement with Eliot here.  A point of distinction is that it's easy to document what we do with our implementation, but harder, or impossible to document what we don't do.  I don't understand the all of the fine intricacies of DITA, but, in DITA I see a standard that might actually continue to have legs and create great value for entire organizations. These fringe Documentation, Compliance, marketing and sales group can ultimately feed into Tech Pubs, translation systems and the broader publishing effort. At last week's Gilbane Conference, in response to questions about the implementation of DITA outside of Tech Pubs, some of the Gilbane Consultants emphasized that, "Just because something can be done technically doesn't mean it should be done."  On the other hand many large global organizations are getting tremendous value in their Tech Pubs groups by implementing the full DITA tool standard.

I applaud the technical committee for its commitment and forward thinking approach to the emerging DITA standard.

Most of our customers, who I emphasize, are generally not in Tech Pubs, don't want to understand the DITA standard any more than they wanted to learn PostScript.  A end of conference theme, in response to JoAnn Hacko's question about why DITA seems to have more legs in the US than in Europe at DITA Europe was that DITA is "too complex".  I think this comment really means, "we don't understand DITA and we don't know how to implement it and we can't afford consultants and a new layer of technical implementers for the organization at large.  These companies seem to see the potential benefits of XML and DITA, but ideally want to endure "just in time" and "just enough" DITA.

Simply XML has just initiated a project called Operation DITA Launch where, in a series of 6 one hour meetings during Q1, we will discuss how to implement DITA outside of Tech Pubs.  The group now includes three members of the technical committee and a larger number of company representatives from around the globe.  This will not be a forum on DITA, but hopefully, a platform of experimentation where we will all learn something about DITA and implementing it across the enterprise.  I'll report back to the group on the issues experienced and solved by the companies in Simply DITA Launch.

-----Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com] 
Sent: Monday, December 06, 2010 11:57 PM
To: Su-Laine Yeo; dita; dita-adoption@lists.oasis-open.org
Subject: Re: [dita] RE: [dita-adoption] Re: [dita] who complains about complexity of DITA?

In the conformance clause we tried to make it clear (or at least clearer)
that conforming tools need not support all of DITA in order to be
conforming. The intent was specifically to allow tools that do not support
the full vocabulary or full set of non-mandatory features to still be
conforming and thus be said to legitimately "support" DITA. All we ask in
return is that tool suppliers clearly document what their tools do and don't

We also tried to distinguish tools that are fully general, meaning they can
handle any DITA vocabulary module, from those that only recognize or support
specific vocabulary modules. Both types of tools are useful.

Su-Laine's caution about providing good user experience is an important
one--if I want best experience for creating learning materials I might well
look for an L&T-focused authoring environment that is not a general DITA
tool. On the other hand, I would necessarily expect a general-purpose
DITA-aware editor to provide any special feature for learning content (at
least not as part of the base product).

The constraint mechanism provides a formal way for tools to indicate what
they do and don't support by saying "We support documents that conform to
this and that set of constraints but not others". This lets tool suppliers
be crystal clear about what they do and don't support, which is the real
challenge with a standard like DITA: clarity of intent and support.

As regards various forms of "simple DITA" I am in complete agreement: the
DITA architecture has been carefully crafted to allow exactly such
subsetting and there is obvious value in it. The constraint mechanism is for
doing exactly that.

I think part of the problem we're seeing is a hopefully historical legacy of
tools supporting *only* the TC-provided all-inclusive document type shells
and nothing else and not making it either possible to have other shells or
at least not making it easy to have them. I think that is changing (I hope
it is). 

I think we need to work hard to educate the community that DITA is not just
another giant vocabulary but a framework for building the vocabulary you
need while ensuring widest possible, lowest-impedance interchange. This is
what truly distinguishes DITA from all other vocabularies, standard or

Our challenge, of course, is to them provide some ready-made pre-built
vocabulary packages tuned for specific use cases. And we see that happening
in the Busdocs SC, in DITA for Publishers, in the Simply DITA effort, and

I think we also need to have some confidence that these efforts will serve
to largely address the concerns we've been hearing--it will take time but it
will get done.

I think we as a TC can also assure ourselves that there are no features of
DITA that are not absolutely essential for at least some significant use
case and body of users.



On 12/6/10 5:05 PM, "Su-Laine Yeo" <su-laine.yeo@justsystems.com> wrote:

> Good questions. I have some thoughts on the motivations/causes of the
> complaints from the user community, but I'd like to hear from others on this
> issue first.
> Regarding the impact of number of element types on tool vendors: I think it
> might be difficult for tool vendors to take a public position on whether they
> think there are too many element types in DITA. However, I can say that
> supporting more element types *with an optimal user experience* requires a
> substantial amount of work for tool vendors. Supporting a particular set of
> element types well can require understanding the needs of a particular market
> segment, and the vendor might not even be interested in in selling to that
> segment. 
> On the other hand, supporting DITA element types poorly is really cheap and
> easy to do. If we force every vendor to support the same large package of
> special-purpose element types in order to say they support DITA, what we will
> generally encourage is that vendors deliver tools with poor or uneven support
> for a wide range of market segments.  It would be better for the DITA
> community as a whole if we create an environment that encourages vendors to
> deliver excellent tools for targeted market segments.
> Cheers,
> Su-Laine
> Su-Laine Yeo
> Solutions Consultant
> JustSystems Canada, Inc.
> Office: 1 (778) 327-6356
> syeo@justsystems.com <mailto:syeo@justsystems.com>
> XMetaL Community Forums: http://forums.xmetal.com
> For partners only: http://www.justpartnercenter.com
> From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
> Sent: Monday, December 06, 2010 8:16 AM
> To: Bruce Nevin (bnevin)
> Cc: dita@lists.oasis-open.org; dita-adoption@lists.oasis-open.org
> Subject: [dita-adoption] Re: [dita] who complains about complexity of DITA?
> I'm also curious about this. Even before we had constraints, we had basic DITA
> modularity, which lets you include or exclude whole domains of elements at a
> time. And the doctypes we package with the spec do exactly that.
> Simple number of elements in the spec as a whole shouldn't be a measure of
> complexity for either authors or architects, since you only include or work
> with the elements that matter for your domain. For example, the learning and
> training specializations don't increase complexity for authors or architects
> in basic tech comm.
> So do we really have a complexity problem, that is it's too hard to use DITA
> or create new DITA specializations? Or do we have a communication problem,
> about how to use DITA (start small, include what you need, don't try to use
> stuff you don't need)? Or are there other problems, outside the domain of the
> spec, like customizing processing flows, that get reflected back on the spec
> even though it's really something outside our control?
> I don't mean to dismiss complaints about complexity, but like you I think we
> need to understand the actual motivations/causes of the complaints before we
> can usefully react.
> Michael Priestley, Senior Technical Staff Member (STSM)
> Lead IBM DITA Architect
> mpriestl@ca.ibm.com
> http://dita.xml.org/blog/25 <http://dita.xml.org/blog/25>
> From: "Bruce Nevin (bnevin)" <bnevin@cisco.com>
> To: <dita@lists.oasis-open.org>, <dita-adoption@lists.oasis-open.org>
> Date: 12/06/2010 11:01 AM
> Subject: [dita] who complains about complexity of DITA?
> Are we entirely clear about the use contexts in which users find the number of
> elements onerous or confusing? Obviously, the authoring environment is one.
> But do architects also object? Do the tools vendors object? This seems less
> likely to me, but it's not something to guess, we should find out. And is that
> (the number of elements) the only complexity that they object to?
> The constraints mechanism can neatly address the perceived complexity in the
> authoring environment. (Be it noted that existing mechanisms provided by
> [some?] authoring tools to hide elements from authors apparently do not reduce
> these complaints, maybe because the complaints come from users who don't make
> use of them.) But creating and managing constraints is another layer for
> architects and designers to deal with.
>     /Bruce 

Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368

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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]