My
overnight thoughts led to "type vocabulary".
"Vocabulary" is attractive because of the connotations
that Robin mentioned.
vocabulary - a collection of related terms for
describing a subject matter area
Any
type system includes notions of (a) how to identify the things
and
(b)
which things are significantly different. Each element type is
identified
by its
name, and distinguished from other element types by its internal
structure.
The
element types are the individuals that are being collected into a
vocabulary.
The
names of the element types are the names that enter the
vocabulary,
and
the structures of the element types are the semantics for the
names.
What
we are building when we combine type modules is a vocabulary
based
primarily on element types. These are the most common types
in
DITA, and are the ones we mean when we casually say "type".
So we
are building a vocabulary of types, or "type vocabulary".
The
next question is whether to call it that!
If
"vocabulary" is an elliptical way of saying "type vocabulary",
and
we all
understand the derivation of the term the same way,
then
"vocabulary" would suffice.
Regarding "document type", I would argue that this is a
misleading term.
It's a
fragile argument, but I'll try it anyway.
Documents are at the instance level. A type vocabulary
is at the type level.
A type
vocabulary provides types for elements. The element types tell
you
what
the legal structure of an element instance is. It is the
ensemble
of
element instances that make up a document instance.
But
the document instance doesn't have a corresponding
complex type, with all the structure that the document
instance has.
That
complex type is constructed implicitly when a typechecker
verifies that a document instance is valid. If
anything, that would
be the
document type.
The
type vocabulary is a collection of element types, and that is
the thing we are looking for a name for. If the
collection needs to be viewed as grammatical system, we might introduce
a further term, such as "vocabulary system" or
"grammar".
One of
the strengths of DITA compared with a more mechanistic view of XML and what
it can do for you is the emphasis in the DITA architecture on a
precise understanding of types and modules. For this reason, where the DITA
point of view necessarily differs from that of the larger
community, I'd rather offer and argue in favor of the DITA point of view than
adopt an external precedent without
discussion.
Bruce
Esrig
-----Original Message-----
From: Michael Priestley
[mailto:]
Sent: Friday, October 01, 2004 11:24
AM
To: Robin Cover
Cc: OASIS DITA TC
Subject:
Re: [dita] proposal on "vocabulary" terminology
I'm confused. How is "document type" misleading?
When we assemble modules using a shell
file, it is literally into a document type. My main reservation was that I was
told "document type" was a DTDism, but it looks like it isn't.
I'm now definitely prefering "document
type" for a couple of reasons:
1)
it is literally accurate
2) it is the
terminology already in use by the most famous modularized DTD/schema around,
XHTML.
Michael
Priestley
Dept PRG IBM Canada phone:
416-915-8262
Toronto Information Development
Robin Cover
<>
10/01/2004 12:04 PM
To:
OASIS DITA TC <>
cc:
Subject: Re: [dita]
proposal on "vocabulary" terminology
I try not to have opinions about terminology unless it
appears
critical to avoid misleading users (through adoption of
a
definition that's counter-intuitive). In this case it
feels
fairly important.
For the target object, "document type" feels
wrong because it's
already overloaded with explicitly defined precise
meanings (as
well as with not-so-precise related usages).
I would
prefer "vocabulary" in this setting because it most
easily leads one to
think about a set of names (lexical features)
represented in the collection
of all names in the set. That's
more to the point than "type," which
carries other connotations
from its usage in many computing domains and
formalisms.
"Vocabulary" isn't overloaded as far as I know in its use
as
a precise term -- and I had forgotten about the XML Namespaces
spec,
where it refers to element and attribute names (but
apparently not to names
in PIs, entities, notations, etc). Few
people are going to be misled
because of the usage in Namespaces.
Most users, I think, will get the
right idea correctly from
"vocabulary" because it's an imprecise word for a
collection of
named markup constructs, including elements, attributes
and
related named aggregations of constructs.
My $0.00002
-
Robin
On Fri, 1 Oct 2004, W. Eliot Kimber wrote:
> JoAnn
Hackos wrote:
> > 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
>
> "document type" is
certainly the most accurate if you take it to mean
> "abstract document
type" (that is, a set of types distinct from any
> implementation
expression of them) but I think that most people don't
> make that
distinction, especially people like many of us with deep SGML
> brain
damage, where there was no obvious need to distinquish between the
>
abstract document type and its syntactic expression.
>
> That's
one reason I prefer "vocabulary"--it's completely (and in the
>
namespace spec, explicitly) divorced from any particular syntactic or
>
formal definition or expression of the vocabulary.
>
>
Cheers,
>
> E.
>
--
