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] RE: Vertical Industry Vocabulary in DITA 1.3

I fully agree to what is being said.

“… moving vertical vocabulary into
separate specifications, reserving the base vocabulary for things that are
either of universal utility or essential to the architecture as a whole. We
should not be adding any new attributes or elements that are specific to any
particular industry or use domain.”

But my proposal is not about specializing machine industry specifics to the base vocabulary; on the contrary the proposal is about generalizing the base vocabulary to not include, what I interpret is, domain specific markup.

Let me explain how I think. The filtering attributes, product, platform, audience and otherprops are semantically implying a domain; software products (and maybe some other domain). Some user of DITA, managing for example business legal documents in the music industry, I assume would have difficulties in interpreting the attributes in their context. To replace (or add along with) the filtering attributes with the more generic “subjectref” attribute is about cleaning up and make the conditionalizing architecture universal, since subjectref doesn’t semantically imply a domain (at least not to me). In fact, I've seen many implementations where the filtering attributes are used for other purposes than indicate a product or platform.

So probably the proposal would need a change in DITA 1.3 as stated in “…We could back-define those attributes as @props specializations in DITA 1.3 if we wanted to since that would change any functional aspects of those attributes or processors that recognize them today based merely on their names.”

To me the DITA 1.2 filtering attributes/DITAval architecture and the subject scheme can make complex situations. For example

  <title>Products A, B</title>
  <topicref href="products.dita" platform=”only_mswin”>
      <subjectref keyref="only_linux"/>

This example states that the topic is classified for linux but conditionalized for mswin. Of course the way we classify or conditionalize has different purposes; to tell what subjects the topic is treating for retrieval vs putting a condition to be able to filter out a specific piece of content. But my experience is that these two perspectives often are the same.

I fear that the DITA 1.2 filtering attributes/DITAval architecture and the subject scheme are two systems in parallel that to some extent overlaps each other, making life complex for users. To “merge” the two systems could maybe reduce complexity? Or maybe the recommendation is to not conditionalize parts of a subject scheme map?

From: Eliot Kimber [ekimber@reallysi.com]
Sent: Wednesday, February 23, 2011 8:26 PM
To: Su-Laine Yeo; dita
Subject: Re: [dita] RE: Vertical Industry Vocabulary in DITA 1.3

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.


Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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