[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]