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