RE: [dita] Organization of the DITA Specification

["Mary McRae" <mary.mcrae@oasis-open.org>]

Hi everyone,

  I just wanted to point out a couple of practical matters related to
specification organization. Basically, a specification moves through the
lifecycle as a single unit. You can have a single unit such as the DITA 1.1
specification (includes an overview, both the architecture and language
specifications, and  DTDs and schemas. For 1.2 you could include the various
specifications as part of the DITA 1.2 specification, or you could treat each of
those as separate specifications - profiles if you will - which are processed
and managed separately, although certainly associated with the main spec. So you
could have DITA 1.2, and then have Machine Language Specialization for DITA 1.2,
Learning Specialization for DITA 1.2, etc. with each of those having their own
separate public reviews, and Committee Specification and OASIS Standard ballots.
If one all-inclusive specification is processed through the lifecycle, any
distribution of the DITA 1.2 specification would need to contain all of the
components.

  Note that all specifications must now include conformance statements; these
statements can help make dependencies clear with regard to specializations.

  Sorry for the interruption but hopefully that input will help with this
discussion.

Regards,

Mary

> -----Original Message-----
> From: Ogden, Jeff [mailto:jogden@ptc.com]
> Sent: Monday, January 28, 2008 6:43 PM
> To: dita@lists.oasis-open.org
> Subject: RE: [dita] Organization of the DITA Specification
> 
> For myself I'd like to see us provide several different packages
> (.zips):
> 
> One package for the core specs, DTDs, and schemas.
> 
> One package for each specialization family that would include the specs,
> DTDs, and schemas for that family, but not for the core.
> 
> A super package that contains all of the specs for everything, but none
> of the DTDs or schemas.  Not sure if this super package should both the
> source and the composed outputs for the specs or just the composed
> outputs. In any case would like to see PDF, Web, and HTML Help outputs
> included.
> 
> A super package that contains everything (core, all families, all specs,
> all DTDs, and all schemas).
> 
> The organization of the DTDs and schemas into families would mimic the
> new organization of the specs.
> 
> The contents of the super packages would be made up from the contents of
> the individual packages and have the same structure as the individual
> components in the individual packages. Or said another way, you would
> still be able to see the structure of the individual packages within the
> super packages.
> 
>     -Jeff
> 
> > -----Original Message-----
> > From: Robert D Anderson [mailto:robander@us.ibm.com]
> > Sent: Monday, January 28, 2008 6:03 PM
> > To: dita@lists.oasis-open.org
> > Subject: [dita] Organization of the DITA Specification
> >
> >
> > Hi - I intended to send this out last Friday, but am just now getting
> to
> > it
> > - so it will sound a bit rushed.
> >
> > The TC needs to put a small amount of thought into how the
> Specifications,
> > including DTDs and Schemas, will be distributed with DITA 1.2.
> >
> > There are now a couple of industry specific packages, with more to
> come in
> > the future. Should these be bundled with the core? If in separate
> packages,
> > should they include pre-requisite portions of the core, or must users
> > download more than one package? What exactly is the core?
> >
> > For example - how should one be able to access the machine industry
> > specializations? It uses the task specialization, which (so far) is
> one of
> > the core information types. So, would a Machine Industry bundle also
> > include the task DTD and Schema modules, or the task specification?
> >
> > Is there still a reason to have one large bundle with all of the DITA
> > specifications in a single zip? I wonder if - in the future - it will
> be
> > useful for a single user or implementer to grab every industry bundle
> at
> > once.
> >
> > Anyway - this is just a rather rushed way to bring up the topic. If we
> > have
> > time at tomorrow's call, we can discuss it in more detail. If there
> are no
> > opinions from the rest of the TC, then those working on the spec will
> be
> > forced to decide before too long.
> >
> > Thanks -
> >
> > Robert D Anderson
> > IBM Authoring Tools Development
> > Chief Architect, DITA Open Toolkit
> > (507) 253-8787, T/L 553-8787 (Good Monday & Thursday)
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and 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.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php