Is there a reason that we
cannot use "document type" except for an intrusion into the DTD world? I think
information developers and architects are more likely to understand the term
"doc type" rather than a more esoteric term like "vocabulary"? I'd like to err
on the side of usability and user-centeredness if possible.
JoAnn
From: Michael Priestley
[mailto:]
Sent: Thu 9/30/2004 9:14 AM
To:
W. Eliot Kimber
Cc: OASIS DITA TC
Subject: Re: [dita]
proposal on "vocabulary" terminology
How about "vocabulary" or "document
vocabulary"?
Example:
You can integrate modules for different
information types and domains into a single document vocabulary (document type
or schema) using a vocabulary shell (a DTD or schema shell file that points to
the module files and indicates how they are to be integrated).
I would use "document type" since it is
literally accurate, but I'm told that usage is specific to DTDs and would not be
appropriate for documents based on schemas.
Michael Priestley
Dept PRG IBM Canada
phone: 416-915-8262
Toronto Information
Development
"W. Eliot Kimber"
<>
09/29/2004 09:52 AM
To:
OASIS DITA TC <>
cc:
Subject: Re: [dita] proposal on
"vocabulary" terminology
Erik Hennum wrote:
> To resolve these concerns, Michael and
I would like to propose the
> following enhancements to the formal DITA
terminology:
>
> * Where the formal terminoloy currently uses
"vocabulary" instead use
> "vocabulary shell"
New proposal to
replace "vocabulary shell": "encompassing vocabulary".
Justification and
discussion:
In the con call on Tuesday, I raised an issue with the term
"shell" in
this context.
My primary concern is that going forward we,
as users and practioners
creating DITA-based applications (that is,
use-specific XML applications
that either specialize the DITA-defined
modules or use the DITA
architecture mechanism to specialize from some other
base), need a way
to talk clearly about both modules from which one
specialize, as well as
the fully-realized XML document types created by
combining modules and
specializing from them. Currently we have no good term
for this,
certainly not one that is clearly distinguished from a particular
syntactic expression of the document type.
That is, it's easy to talk
about a "shell DTD", which is a set of DTD
declarations that syntactically
pull together a set of DTD modules to
form a single *syntactic* document
type declaration. It's quite another
to talk about the abstract thing that
the syntactic DTD is an
implementation expression of.
In my normal
practice I use "DTD" or "declaration set" to refer to the
syntactic DTD
declarations and "document type" to refer to the
abstraction. But in this
context "document type" is both too generic and
too overloaded to be
reliably understood in this precise way.
Thus my concern that we get this
terminology correct. Note that in this
discussion I have essentially zero
concern for existing DITA users and
the terminology they currently use--they
are sophisticated and their
numbers are small. My concern is entirely for
future users of DITA.
My reasoning is thus:
1. The thing being
described is the (conceptually) *abstract* set of
element types formed by
combining one or more architectural modules to
form an "encompassing"
document type. [The term "encompassing documen
type" is taken from it's use
in the HyTime standard, where we defined it
to mean a document type that is
intended to account for all the element
types to be used in a given document
instance, as opposed to a document
type that is intended to account for a
subset of the types that would be
used in a document. In the DITA context,
the "concept" document type is
encompassing, the "concept" module is
not.]
2. The word shell was originally used to describe a *syntactic*
construct, the actual .dtd file used to pull together the relevant
declarations.
3. The thing being described is distinct from any of
its possible
syntactic expressions, which could include DTD declarations,
WSD
schemas, etc.
4. Therefore, "shell vocabulary" could be taken to
imply a syntactic
construct when it is not intended in that way.
5.
We need a clear term by which we can talk about the set of types
distinct
from any syntactic definition of them. For example, the
DITA-defined
"concept" document type is an instance of what Erik has
proposed calling a
"vocabulary shell".
I proposed "concrete vocabulary" as a possible
alternative for
"vocabulary shell" but I'm not particularly happy with
that.
I chose the word "concrete" to emphasize that the set of types is
intended for use with document instances, rather than being intended
only as a base for specialization.
However, it is a fact that any
concrete set of types could also be
specialized, so there is potential for
confusion with concrete/abstract
in this context, which is entirely a
function of use and context, and
concrete/abstract in the context of
object-oriented programming, where
classes can be declared as "abstract",
meaning that they can only be
used for specialization, they cannot be used
for class instances.
Terms like "module collection" or "module set",
while accurate, are not
particulary
descriptive.
Cheers,
Eliot
--
W. Eliot
Kimber
Professional Services
Innodata Isogen
9390 Research Blvd,
#410
Austin, TX 78759
(512)
372-8122
www.innodata-isogen.com
