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] C/T/R Not Universal (was problem with packaging of glossaries)


I think we need to take a deep breath here and everyone calm down. I agree
that the market for publishing use cases is greater than that of TD and so
is BusDocs. And yes they are all topic oriented in some way or another and
there are many advantages of using DITA vs custom or DocBook as you have
indicated in your response. 

The concern BusDocs has in relegating task, concept, reference and glossary
to TD ONLY when there are potentially other uses in materials outside of TD.

-----Original Message-----
From: ekimber [mailto:ekimber@reallysi.com] 
Sent: Monday, August 24, 2009 12:57 PM
To: rob@ascan.ca; dita
Cc: 'Bruce Nevin (bnevin)'; 'Michael Boses'; tgrantham@timgrantham.com;
'Michael Priestley'; 'JoAnn Hackos'; rockley@rockley.com
Subject: Re: [dita] C/T/R Not Universal (was problem with packaging of
glossaries)

On 8/24/09 11:44 AM, "Rob Hanna" <rob@ascan.ca> wrote:

>> In traditional publishing content, such as trade books or novels
>> or magazines, the distinction between "concept" and other stuff
>> is not one that is generally recognized or useful.
> 
> Traditional publishing content is not topic-based nor is it
> semantically-structured. I don't believe that we can use this as a basis
for
> discussion pertaining to the usefulness of core information types. Any
> environment where topic-based content is used to explain, describe, or
> instruct will be able to leverage the semantics contained within the DITA
> archetypes. I would think that the majority of DITA adopters would fall
into
> this category.

So you're saying all the work I've done over the last two years to use DITA
to implement Publishing workflows and DITA-based management of content is
somehow wrong?

The point of using DITA in this context is to take advantage of these
features of DITA, in this order of priority:

1. Specialization. Specialization lowers the cost of startup and ownership
of XML applications by a factor of around 80% compared to traditional
development methods and standards. This makes the use of DITA hugely
compelling for *any* content for which DITA can be applied at all.

2. Modularity. Many publishing business challenges revolve around taking
traditional monolithic publications (books and magazines) and reusing and
repurposing their content to new packages and new channels. The modularity
features of DITA are well suited to this business problem, providing a ready
markup design and implementation infrastructure that again lowers the cost
of acquisition and ownership.

3. Interchange. DITA by its nature (and primarily through the Specialization
facility, but also through important constraints in conref) enables *blind*
interchange of content among partners as long as all content conforms to the
DITA specification. This is of vital importance to Publishers who want to
license content in a way that provides the greatest value to licensors. DITA
satisfies this requirement better than any other existing standard.

In fact, I maintain that the potential user community for Publishing-related
uses of DITA is 10 times greater than the potential user community for
technical documentation users. That suggests to me that the concerns of that
community should be of tremendous interest to us as a committee, to tool
vendors, and to services suppliers.

Much publishing content is in fact quite topic-based by its nature, *but not
by its traditional development and management methods*. Magazines, for
example, are nothing more than collections of topics (articles). By the same
token, much publishing content is quite semantically rich, especially in the
area of metadata and phrase-level identification (mentions), but traditional
publishing tools have not provided good ways to express it or take advantage
of it.

Cheers,

Eliot

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://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 



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