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 practical problems related to packaging


Does the TC have the daring to eat its own dogfood?  ?-> 

> -----Original Message-----
> From: ekimber [mailto:ekimber@reallysi.com] 
> Sent: Wednesday, August 26, 2009 4:09 PM
> To: Bruce Nevin (bnevin); Kristen James Eberlein; 
> seth.park@freescale.com; dita
> Subject: Re: [dita] Some practical problems related to packaging
> 
> On 8/26/09 2:56 PM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote:
> 
> > Seth, I do believe that the motivation for peeling away the base 
> > package has substantial value, namely, providing the 
> simplest possible 
> > setup for implementers to get their feet wet and figure out 
> how it all 
> > works before delving into the daunting complexities.
> >  
> > Presenting the training stuff separately also has value, since many 
> > existing and new users will not want to have to wade past a raft of 
> > new elements and attributes that they never use.
> >  
> > The problem you identify, Kristen, could best be solved using 
> > simplified topic types in 1.3, intermediate between <topic> and the 
> > current C/T/R types.  For now, we may have to tell them 
> that if they 
> > want to use the sources of the base docs as examples of how 
> it's done, 
> > they'll have to do so in context of the more extensive 
> package that is 
> > equivalent to 1.1.
> 
> It could also be solved by treating the spec for what it is: 
> a specific application of DITA that will require its own 
> supporting infrastructure, including specializations, plugins 
> with schemas and DTDs, processing extensions, etc.
> 
> The nature of DITA is that it cannot be adequately documented 
> by its most minimal expression.
> 
> Or said another way, the DITA specification is itself a 
> technical document that appropriately requires the tech doc 
> package. I don't see that as a problem. 
> 
> Another solution would be to generalize all the topics to 
> <topic> for the purposes of packaging with the base 
> module--that's actually the first compelling real-world use 
> of generalization that I've seen...
> 
> 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> 
> 
> 
> ---------------------------------------------------------------------
> 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_workgr
> oups.php 
> 
> 


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