I'm
not sure we can really do that, since specialization would imply another level
of hierarchy - the creation of a new root document-type element specialized from
this one.
Rather
it seem like in this "Specialization" section we need to cover four distinct
levels of possible implementor intervention, ranging from the least divergent
from the "normative" base we deliver to the most:
just
a shell
contraints
specialization
customization
I've
already suggested in my comments we consider revising this section as
such.
-----Original Message-----
From: JoAnn Hackos
[mailto:]
Sent: Tuesday, June 30, 2009
10:52 AM
To: Dana Spradley; Ogden, Jeff; dita
Subject: RE:
[dita] some comemnts on the Draft DITA 1.2 architecture
spec.
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.
