Should not we always refer to such changes
as “specializations” rather than “customizations”?
JoAnn Hackos PhD
President
Comtech Services, Inc.
Skype joannhackos
From: Dana Spradley
[mailto:]
Sent: Tuesday, June 30, 2009 11:46
AM
To: Ogden, Jeff; dita
Subject: RE: [dita] some comemnts
on the Draft DITA 1.2 architecture spec.
Is
"customized"/"customization" really appropriate here? Are
is this something we're considering less drastic than customization?
-----Original Message-----
From: Ogden, Jeff
[mailto:]
Sent: Monday, June 29, 2009 7:37
PM
To: dita
Subject: [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.
