OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] proposal on "vocabulary" terminology

On Fri, 1 Oct 2004, Michael Priestley wrote:

> I'm confused. How is "document type" misleading?

I didn't mean to claim that it "is" confusing, and can't prove that it
would be troublesome to a significant number of users.  I suspect
it's not the best label to help users think clearly about the 
role/function of the shell/driver files.

> 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.

Formally, "document type" may not be a DTDism, but for many users,
I think, "document type" is closely associated with both
document type declaration and document type definition, both of
which relate to a grammar.  Grammar in SGML and XML is a lot
more about syntax than about lexical semantics.

In the problem at hand (optimally clear terminology for
"DTD shell file" and "schema shell file" as driver files to
construct DTDs/schemas, I thought "document type" was a
less ideal label.  I don't plan to defend or explain
these oppositions (partly because I imperfectly understand
the DITA problem), but I feel it's a matter, relatively
speaking, of:

a) (syntactic) form vs. function
b) concreteness vs. abstractness
c) meta vs even-more-meta

Of these, I feel the force of "a)" most.  I would not claim that
the XHTML spec is "wrong" in its choice of terms, but perhaps
infelicitous.  The key notion in XHTML modularization, IMO, is
the ability to combine declarations for document objects in
new ways so that the new instance documents have all the cool
objects we want.  Conceived in this way, the mechanism is
syntactic but the focus is upon the document objects that
are allowed/disallowed under the modularization goals.  If
we use documents that have type to generate other
formalisms that define new document type, it may not be
incorrect to reference the former as document types, but
I think we would want a term which more clearly describes the
*function* of these files in the modularization architecture
and process.

Enough from me; I defer to the rest of you.


> 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
> mpriestl@ca.ibm.com
> Dept PRG IBM Canada  phone: 416-915-8262
> Toronto Information Development
> Robin Cover <robin@oasis-open.org>
> 10/01/2004 12:04 PM
>         To:     OASIS DITA TC <dita@lists.oasis-open.org>
>         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.
> > 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]