OASIS Darwin Information Typing Architecture (DITA) TC

 View Only

  • 1.  Organization of the DITA Specification

    Posted 01-28-2008 23:03 
    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)


  • 2.  Re: [dita] Organization of the DITA Specification

    Posted 01-28-2008 23:09 
    FWIW, I'd rather see them separated into separate downloadable specs and 
modules. If you don't need them, why should we force you to download 
them in one huge package?

Best regards,

--Scott

Robert D Anderson wrote:
> 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 
> 
>


  • 3.  Re: [dita] Organization of the DITA Specification

    Posted 01-28-2008 23:16 
    Robert D Anderson wrote:
> 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.

I think that application-specific specializations, including bookmap and 
all industry-specific specializations should be packaged separate from 
the base DITA spec and working declarations. That is, they are, 
fundamentally, no different from any other user-defined specialization 
from a packaging standpoint.

That is, when one publishes a Java library you don't, by default, 
package it with Java, you just state the requirement with the reasonable 
assumption that most interested parties will already have the prereqs in 
place.  I think the same should be true for DITA.

This also makes it clearer what is core (topic, task, concept, 
reference) and what is standard but optional.

One potential problem with including the declarations in specialization 
packages is keeping all the packages in sync when new releases of the 
base packages are made (e.g., to fix bugs).

There is already confusion among users (and some implementors) as to 
what is and isn't required.

Cheers,

Eliot

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com


  • 4.  RE: [dita] Organization of the DITA Specification

    Posted 01-28-2008 23:43 
    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


  • 5.  RE: [dita] Organization of the DITA Specification

    Posted 01-29-2008 01:59 
    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


Related Content