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?


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



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