|Erik Hennum||Sep 26, 2004 9:09 am|
|Michael Priestley||Sep 28, 2004 8:55 am|
|Michael Priestley||Sep 28, 2004 8:55 am|
|W. Eliot Kimber||Sep 29, 2004 6:49 am|
|Michael Priestley||Sep 30, 2004 8:14 am|
|JoAnn Hackos||Sep 30, 2004 11:24 am|
|Michael Priestley||Sep 30, 2004 12:08 pm|
|Erik Hennum||Sep 30, 2004 2:39 pm||.gif, .gif, .gif, 8 more|
|Deborah Aleyne Lapeyre||Sep 30, 2004 5:13 pm|
|W. Eliot Kimber||Oct 1, 2004 6:32 am|
|Robin Cover||Oct 1, 2004 8:12 am|
|Michael Priestley||Oct 1, 2004 8:23 am|
|Michael Priestley||Oct 1, 2004 9:12 am|
|Esrig, Bruce (Bruce)||Oct 1, 2004 9:13 am|
|Michael Priestley||Oct 1, 2004 9:34 am|
|Robin Cover||Oct 1, 2004 11:09 am|
|Subject:||RE: [dita] proposal on "vocabulary" terminology|
|From:||Esrig, Bruce (Bruce) (esr...@lucent.com)|
|Date:||Oct 1, 2004 9:13:39 am|
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.
-----Original Message----- From: Michael Priestley [mailto:mpri...@ca.ibm.com] 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 mpri...@ca.ibm.com Dept PRG IBM Canada phone: 416-915-8262 Toronto Information Development
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.
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. >