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] Specification outline - adding more detail


At 01:20 2004-07-13 -0400, Michael Priestley wrote:

>Feedback welcome. One thing to think about: can we get away with less
>detail in part 1 (map and topic markup) and just point to the DTD and
>schema files, as DocBook does?

I'm a little confused, as part 1 seems to be the intro below.

Regardless, my answer depends on what you mean by "less detail".
I see no need to go into great detail in all the topics you list,
but I do think a few words about each topic would be very useful.

Remember, part of what we want out of this spec is something people
can learn from.  Just pointing to a DTD may, in theory, be sufficient
for someone who has the drive to figure it all out, but we wouldn't
be doing ourselves a big PR favor by doing that.  Rather, we should
strive to make our 1.0 spec easy enough to read that it helps sell DITA.

So for all the "why XXX?" topics, no need to wax poetic, but just a 
sentence or two.  Likewise with the rest of the topics.

I like the outline--we should just fill it out now without writing
a PhD thesis on each topic.  (Well, of course, by "we", I mean you!)

paul


>1. intro
>
> about dita
>   modularization and integration (shells)
>   mime type and file extension
>   namespace, public identifier, system identifier
>   compatibility with other standards efforts
>   terminology
>   definitions/concepts
>     information types
>     domains
>     integration
>     customization
>     specialization
>
>2. document structure
>
>2.1 common attributes and metadata elements
>
>common attributes
>  id and conref
>    contrast with sgml conref and with xinclude
>  metadata attributes
>  lifecycle and language
>  escape hatch (outputclass)
>  architectural (class and domains)
>
>common metadata elements
> publication
> management
> metadata
> processing
>
>2.2 DITA content
>
>topics
>  why topics?
>  topic structure
>   labels and descriptions
>   prolog content
>   body content
>     sections and examples
>     blocks
>     phrases
>   links and nesting
>   modules: dtd\topic.mod, xsd\topic.mod
>   in use: concept.*, ditabase.*
>
>information types
>
> concepts
>  why concepts?
>  concept structure
>  modules, in use
>
> tasks
>  why tasks?
>  task structure
>  modules, in use
>
> reference
>  why reference?
>  reference structure
>  modules, in use
>
>domains
> programming - why, what, modules
> software - "
> user interfaces - "
> utilities - "
> highlighting - "
>
>2.3 DITA maps
>
>common DITA map attributes
> collection-type
> processing attributes
> ref common markup attributes
>
>DITA maps
> why maps?
>  builds
>  navigation
>  linking
>  printing
>  metadata
> map structure
>  topic references
>  hierarchies
>  tables
>  groups
> inheritance of attributes and metadata
> modules, in use
>
>map domains
> mapgroup
>
>3.0 DITA specialization
> why specialization?
> specialization, integration, and customization
>
>3.1 specialization in content
> why specialization in content
> class attribute and domains attribute
>  purpose
>  syntax
> generalization
> aggregation considerations
> content reuse considerations
> precedence rules
>
>3.2 specialization in design
> why specialization in design
> modularization and integration, naming schemes
>  purpose
>  syntax
> dealing with namespaces
> rules for DTDs
> rules for schemas
> todos: possible rules for auto-integration, including possible use of a
>dita integration profile
>
>3.3 specialization in processing
> modularization and integration, naming schemes
>  purpose
>  syntax
> customization vs specialization
> dealing with namespaces
> rules for XSL
> rules for CSS



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