RE: [dita] proposal on "vocabulary" terminology

[Michael Priestley <mpriestl@ca.ibm.com>]

Suddenly occurred to me that it would
make sense to see what language they use in the XHTML modularization spec,
since they have exactly the same issues (DTDs and schemas, modules being
assembled to create document types...)

They call em document types, even in
the context of schemas.

http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/

B. Developing Schema with defined and
extended modules 
B.1. Defining additional attributes

B.2. Defining additional elements 
B.3. Defining the content model for
a collection of modules 
B.3.1. Integrating a stand-alone module
into XHTML 
B.3.2. Mixing a new module throughout
the modules in XHTML 
B.4. Creating a new Document Type 
B.4.1. Creating a simple Docoment Type

B.4.2. Creating a Language by extending
XHTML 
B.4.3. Creating a Language by removing
and replacing XHTML modules 
B.4.4. Creating a the new Document Type


Michael Priestley
mpriestl@ca.ibm.com
Dept PRG IBM Canada  phone: 416-915-8262
Toronto Information Development

Erik Hennum@IBMUS 09/30/2004 02:48 PM

To:        "JoAnn Hackos" <joann.hackos@comtech-serv.com>         cc:        "OASIS DITA TC" <dita@lists.oasis-open.org>, "W. Eliot Kimber" <ekimber@innodata-isogen.com>, "Michael Priestley" <mpriestl@ca.ibm.com>         Subject:        RE: [dita] proposal on "vocabulary" terminologyLink

Hi, terminology enthusiasts:

At the risk of making Google more all-powerful
than it should be, the search results suggest that "vocabulary"
has useful connotations for many people:

http://www.google.com/search?hl=en&lr=&ie=UTF-8&q=XML+vocabulary&btnG=Search
http://www.google.com/search?hl=en&lr=&ie=UTF-8&q=XML+%22document+type%22&btnG=Search

The caveat being that search results
are by nature never conclusive.


Hoping that's useful,


Erik Hennum
ehennum@us.ibm.com

"JoAnn Hackos" <joann.hackos@comtech-serv.com>

09/30/2004 11:24 AM

To	"Michael Priestley" <mpriestl@ca.ibm.com>, "W. Eliot Kimber" <ekimber@innodata-isogen.com>
cc	"OASIS DITA TC" <dita@lists.oasis-open.org>
Subject	RE: [dita] proposal on "vocabulary" terminology

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:mpriestl@ca.ibm.com]
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
mpriestl@ca.ibm.com
Dept PRG IBM Canada  phone: 416-915-8262
Toronto Information Development

"W. Eliot Kimber" <ekimber@innodata-isogen.com> 09/29/2004 09:52 AM

To:        OASIS DITA TC <dita@lists.oasis-open.org>        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

eliot@innodata-isogen.com
www.innodata-isogen.com