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: Small DTD bug fix - value list of Note

We have extended the type value list of the note element for DITA 1.2 according to ANSI Z535 with the values NOTICE, CAUTION1, CAUTION2 and WARNING (DANGER and CAUTION have already been available).
According to the announcements of ANSI, they are going to combine CAUTION Level 1 and CAUTION Level 2 für their 2011 release.
To take this attempt into account in DITA 1.2 we can remove the values CAUTION1 and CAUTION2 from the type value list of note, as the values CAUTION and NOTICE will fulfill the requirements well enough.
Best regards


SeicoDyne GmbH
Eichenstrasse 16
CH-6015 Reussbühl
Tel: +41 41 534 66 97
Mob: +41 78 790 66 97
Skype: seicodyne
Member of the DITA Technical Committee
Chairman of the DITA Machine Industry Subcommittee

Von: Ogden, Jeff [mailto:jogden@ptc.com]
Gesendet: Dienstag, 30. Juni 2009 04:37
An: dita
Betreff: [dita] some comemnts on the Draft DITA 1.2 architecture spec.

Some suggestions with additions underlined and blue and deletions strikeout and red:


Concrete document types

A given DITA map or topic document is governed by a concrete document type that defines the set of structural modules (topic or map types), domain modules, and constraints modules that the map or topic can use, as well as the degree of topic nesting that is allowed within the document type. While the DITA specification includes a starter set of concrete document types for common combinations of modules, those document types are not mandatory and, for most many DITA users, include more things definitions than they need for their documents. In general, any production use of DITA involves definition of the DITA users are encouraged to create their own customized concrete document types that include the set of modules best suited to local requirements. This always customization requires the creation of "local shell" document types, even if all they do is omit unneeded modules or apply constraints to the standard DITA-defined vocabulary. Thus you should expect in any production use of DITA that the first step is to define local concrete document types.

Note: The simplest form of local shell is an unaltered copy of one of the DITA TC-provided shells to which is associated a new public identifier or absolute URI, reflecting ownership of the new shell by its creator. For example, to create a local shell DTD for generic maps, simply copy the TC-provided file "map.dtd" to a local location, possibly using a new name for the file to avoid confusion, and create an entity mapping catalog that binds the new copy of map.dtd to a public ID or absolute URI you define, e.g. PUBLIC "-//example.com/DTD DITA NewMap//EN or urn:public:example.dom/dita/doctypes/map urn:example.com:names:dita:xsd:newmap.xsd.

Concrete DITA document types must SHOULD follow the implementation design patterns defined in this specification. This ensures consistency of implementation and also serves to make the task of creating concrete document types almost entirely mechanical.

·         Modularization and integration of design
Specialization hierarchies are implemented as sets of vocabulary modules, each of which declares the markup and entities that are unique to a specialization. The modules must be integrated into a document type before they can be used.

·         DTD syntax specialization design patterns
To be extensible and backward compatible,
DITA requires that a DTD implementation of structural and domain specialization modules SHOULD conform to well-defined the design patterns used for the DTD shells included as part of the DITA specification and described in this topic.

·         XSD schema specialization design patterns
To be extensible and backward compatible,
DITA requires that an XML schema implementation of structural and domain specialization modules SHOULD conform to well-defined the design patterns used for the XML schema shells included as part fo the DITA specification and described in this topic.

While we can require that customized concrete document types follow the rules as outlined in the DITA 1.2 speciication, I don’t think that we can require that they follow the design patterns or that the design patterns are well enough specified to allow them to be a requirement.  At this stage I think the design patters are more of a “best practice” than a requirement that must be followed and so they SHOULD be followed rather than MUST be followed.


It seems likely that the section on “Modularization and integration of design” should be deleted since it is almost entirely repeating information that has been provided in the main section..






For the page dita-1.2-spec/arch/20090617/createConstraintsDomainSpec.html :


I don’t have any comments on the main topic other than to say that it feels as of this topic is saying the same thing two or even three times and that probably isn’t a good idea.



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