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.
