Re: [dita] RE: Vertical Industry Vocabulary in DITA 1.3

[Eliot Kimber <ekimber@reallysi.com>]

On 2/23/11 12:58 PM, "Su-Laine Yeo" <su-laine.yeo@justsystems.com> wrote:

[...]

> One thing though that the DITA TC could do is make sure that vocabulary
> modules do not conflict with each other. E.g. if two specializations
> define the same element name with different meanings, that would be a
> problem for anyone trying to use both specializations at the same time.

This is a good reminder.

Ideally, new vocabulary modules would be in unique namespaces, but that's
not possible in DITA 1.x.

Thus, people creating vocabulary modules for use outside a narrow scope of
application should do something along the lines of what the L&T modules do,
which is use a consistent and reasonably-distinct prefix on all tagnames,
which acts like a namespace prefix but obviously isn't as flexible.

This is essential for domains, less critical for structural specializations
where you can't mix two structural types in the same document except where
you might be physically nesting topics in a single XML document, something
you can always choose not to do.

Within a given use of that vocabulary you can use specialization to then
define what are essentially aliases for the less-friendly name for use
within a narrower scope, as long as those names don't conflict with any
names likely to be used together within that scope.

In DITA for Publishers I've done a bit of a name grab by defining topic
types like "chapter" and "article", but those topic types are so generic
that anyone wanting their own chapter type could constrain from those
modules in any way they want (because those types are all specialized
directly from <topic>).

But my intent with the D4P vocabulary is to be at the same level of
generality as concept/task/reference, whereas L&T is a further
specialization of those general types. But it wouldn't surprise me if part
of making the D4P vocabulary into a formal standard was making the names
more universally unique ala L&T.

Certainly having a general set of well-known vocabulary modules, just as
there is a reasonably well known set of namespaces and conventional prefixes
in common use, would help to minimize name conflict. I'm not sure we should
be trying to create a formal registry of vocabulary modules, but a place to
say "we're working on modules for this application" would certainly be good.

Cheers,

E.
-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com