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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-busdocs 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


Then I would think that any such new base types identified through the
BusDocs work would fall into my "fuzzy area" where we (the TC) have to
decide if they're sufficiently general and useful to add to the core
vocabulary. But nobody should feel they need to wait on that before
proceeding with at least preliminary specialization design.

That is, I think there are two distinct activities:

1. Designing new vocabularies that address specific use cases and
communities of use.

2. Harvesting from those things that are sufficiently general and useful
that they are appropriate for the base vocabulary.

(1) should not need to wait on (2).

And even very general things do not need to be in the base DITA vocabulary
to be widely available and widely accepted, they just need to be widely
accepted. 

Cheers,

E.

On 2/24/11 2:18 PM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote:

> BusDocs covers an open-ended range of vocabularies.
> 
>> -----Original Message-----
>> From: Eliot Kimber [mailto:ekimber@reallysi.com]
>> Sent: Thursday, February 24, 2011 12:32 PM
>> To: Bruce Nevin (bnevin); Jonatan Lundin; Su-Laine Yeo; dita;
>> dita-busdocs@lists.oasis-open.org
>> Subject: Re: [dita] RE: Vertical Industry Vocabulary in DITA 1.3
>> 
>> What stops you from defining these new base types as part of
>> a general BusDocs vocabulary?
>> 
>> Or is the implication these base types would be applicable
>> beyond the scope of business documents?
>> 
>> Cheers,
>> 
>> E.
>> 
>> On 2/24/11 11:29 AM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote:
>> 
>>> This sounds like a wish for less constrained topic types or
>>> information types from which industry-specific types, including the
>>> present <concept>, <task>, and <reference>, would be defined by
>>> specialization, constraint, or other TBD mechanisms.
>>> 
>>> In the BusDocs SC we found that narrative documents in business and
>>> government fall into 'families' with structural/semantic
>> commonalities.
>>> These include the three base types <concept>, <task>, and
>> <reference>,
>>> albeit without their techdocs-specific specializations. They also
>>> include other types that cannot sensibly be specialized
>> from the base
>>> types.
>>> 
>>> At first blush, we would propose that the additional types be
>>> specialized from <topic>. However, the additional types fall into
>>> families with structural/semantic commonalities that would
>> be lost on
>>> generalization if they all had the same common ancestor.
>> There seemed
>>> to us a strong argument that document types within each
>> such 'family'
>>> should have a common ancestor rather than generalization collapsing
>>> everything in the world to <topic>. The aforesaid "TBD mechanisms"
>>> might conceivably mitigate this.
>>> 
>>> A SC white paper on this will be in the mix for 1.3 and 2.0
>> discussions.
>>> However, in the meantime folks grappling with such requirements
>>> outside of tech docs might hope to derive guidance and a
>> big-picture
>>> orientation that can emerge from such discussion, and
>> conversely they
>>> can articulate and substantiate those unforeseen
>> requirements for us.
>>> 
>>>         /B
>>> 
>>>> -----Original Message-----
>>>> From: Jonatan Lundin [mailto:Jonatan.Lundin@citec.com]
>>>> Sent: Thursday, February 24, 2011 10:33 AM
>>>> To: Eliot Kimber; Su-Laine Yeo; dita
>>>> Subject: RE: [dita] RE: Vertical Industry Vocabulary in DITA 1.3
>>>> 
>>>> Hi,
>>>> 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
>>>> 
>>>> <map>
>>>>   <title>Products A, B</title>
>>>>   <topicref href="products.dita" platform="only_mswin">
>>>>     <topicsubject>
>>>>       <subjectref keyref="only_linux"/>
>>>>     </topicsubject>
>>>>   </topicref>
>>>> </map>
>>>> 
>>>> 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?
>>>> 
>>>> Br,
>>>> Jonatan
>>>> ________________________________________
>>>> 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.
>>>> 
>>>> Cheers,
>>>> 
>>>> E.
>>>> --
>>>> Eliot Kimber
>>>> Senior Solutions Architect
>>>> "Bringing Strategy, Content, and Technology Together"
>>>> Main: 512.554.9368
>>>> www.reallysi.com
>>>> www.rsuitecms.com
>>>> 
>>>> 
>>>> 
>> ---------------------------------------------------------------------
>>>> 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:
>>>> 
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.ph
>>>> p
>>>> 
>> ---------------------------------------------------------------------
>>>> 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:
>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
>>>> oups.php
>>>> 
>>>> 
>> 
>> --
>> Eliot Kimber
>> Senior Solutions Architect
>> "Bringing Strategy, Content, and Technology Together"
>> Main: 512.554.9368
>> www.reallysi.com
>> www.rsuitecms.com
>> 
>> 

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



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