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