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

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

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