RE: [dita] RE: [dita-adoption] Re: [dita] who complains about complexity of DITA?

["Rob Hanna" <rob@ascan.ca>]

Good day, Doug et al.

I'm not sure that I see a "violent" departure here. I think that what we
have are two competing imperatives for deployment across the enterprise. On
one hand, we need an intuitive interface into DITA authoring that lowers the
barriers to adoption for business users while on the other hand we need a
rich, scalable architecture that will serve the enterprise. It would be
disingenuous to hand over a completely stripped down version of the standard
and tell them that it is DITA. We might as well hand over XHTML if the
business wants simplicity without semantics. There needs to be a balance.

Moving to structured, topic-based authoring is not business-as-usual. It
represents a paradigm shift for any author. We can and should hide as much
of the complexity as possible but in the end we need to produce something
akin to structure in something resembling topics otherwise it is most
probable that we've selected the wrong architecture.

In the Enterprise Business Documents Sub-Committee, we've been studying
these problems over the past several years. While a quick peak at what we
are doing may appear to be adding layers of complexity, it is necessary at
this point to understand the full breadth of enterprise content to see how
it will scale. Once we have the big picture we can better understand how to
scale it back for first-time adopters. We've been studying this as well with
our aggregated authoring paper, for example.

Speaking on behalf of the BusDocs Sub-Committee, I would like to have
someone from our group join your Operation DITA Launch initiative and hope
that we can get you involved with our work again. Thanks for helping us all
move forward with this!

Cheers!

Rob Hanna
Call: +1 (416) 723-4183
Follow me on Twitter


-----Original Message-----
From: Dgorman@simplyxml.com [mailto:Dgorman@simplyxml.com] 
Sent: Tuesday, December 07, 2010 8:23 AM
To: Eliot Kimber; Su-Laine Yeo; dita; dita-adoption@lists.oasis-open.org
Cc: ErinF@simplyxml.com; MathiasJ@simplyxml.com
Subject: RE: [dita] RE: [dita-adoption] Re: [dita] who complains about
complexity 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
do.

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
otherwise. 

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
elsewhere. 

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.

Cheers,

E. 

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
www.reallysi.com
www.rsuitecms.com


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