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] some comemnts on the Draft DITA 1.2 architecture spec.


I'm not sure we can limit cutomization to just "custom processing."

Customization - that is, using the DITA architecture and reference implementation as the basis of an incompletely conformant xml application of their own design - is something some implementors are going to do.

We have this section now that tries to convince them not to, or at least to limit their divergence and maintain some way of working backward into full conformance - "Limits of specialization and common pitfalls."

Perhaps it should be broken out into a section on "Customization" and expanded a little.

--Dana

-----Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com]
Sent: Tuesday, June 30, 2009 11:48 AM
To: Michael Priestley; Ogden, Jeff
Cc: Dana Spradley; dita; JoAnn Hackos
Subject: Re: [dita] some comemnts on the Draft DITA 1.2 architecture
spec.


On 6/30/09 1:35 PM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote:

> The existing definitions are here:
> http://docs.oasis-open.org/dita/v1.1/OS/archspec/integrate.html
> http://docs.oasis-open.org/dita/v1.1/OS/archspec/customize.html

I see the hierarchy (least drastic to most drastic) as:

1. Integration of existing modules ("local shells")

2. Integration of existing modules and existing constraint modules ("local
shells plus constraints")

3. Definition of local constraint modules

4. Specialization

5. Implementation of custom processing

Note that the implementation of specialized processing is the same base
level of complexity whether you are processing element types from
pre-existing vocabulary modules or handling newly-defined types in new
vocabulary modules: it's the same implementation task.

Cheers,

E. 




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



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