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


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



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