[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
Chris
SeicoDyne
GmbH
Eichenstrasse
16
CH-6015
Reussbühl
Switzerland
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 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
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 Concrete
DITA document types ·
Modularization
and integration of design ·
DTD
syntax specialization design patterns ·
XSD
schema specialization design patterns 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]