[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] some comemnts on the Draft DITA 1.2 architecture spec.
"Ogden, Jeff"
<jogden@ptc.com>
06/30/2009 02:22 PM |
|
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]