RE: [dita] Small DTD bug fix - value list of Note

Hi 
all,

 

Does 
anyone object to making this change to the 1.2 DTDs and schema at this time? IMO 
making this change for 1.2 will prevent folks from using deprecated values later 
when we fix this in 1.3 (if we don't fix it now). The impact on the spec is 
marginal -- only changes to the list of values and minor changes to the 
documentation.

 

I 
would like to propose this change for approval at this week's TC meeting, so any 
discussion on list would help us get to a timely decision.

 

Gershon

From: Christian Kravogel 
[mailto:] 
Sent: Tuesday, June 30, 2009 
5:47 PM
To: 'dita'
Subject: [dita] 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

 

Chris

 

 

SeicoDyne 
GmbH

Eichenstrasse 
16

CH-6015 
Reussbühl

Switzerland

Tel: +41 
41 534 66 97

Mob: +41 
78 790 66 97

Skype: seicodyne

 

www.seicodyne.com



 

Member of 
the DITA Technical Committee

Chairman 
of the DITA Machine Industry 
Subcommittee

 

Von: Ogden, Jeff [mailto:] 

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.