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


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


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