[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita-busdocs] Re: [dita] RE: Vertical Industry Vocabulary inDITA 1.3
Absolutely no problem: the TC doesn't have a monopoly on types, any more than Oracle owns all abstract Java classes and the right/obligation to define them. As for ugly names, I tend to agree--that's the approach used in the L&T specializations and I think it's the only practical approach until we work out how to allow namespace-qualified tag and attribute names. Cheers, E. On 2/24/11 5:20 PM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote: > So you see no problem with folks outside the TC constructing an abstract > layer of information types that are used only as bases for further > specialization of topic types, even simplified forms of <concept>, > <task>, and <reference>? > > Another point that Josef brought up in a recent call. When he wants to > specialize for Pharma, all the "good names" for elements are already > taken in the tech docs base types. He suggested that the bases for > specialization should use "ugly names" that the specializers don't mind, > and then they're free to introduce nicely named specializations for > users to see. (Of course if you don't specialize then you're left with > the unfriendly name.) > > /B > >> -----Original Message----- >> From: Eliot Kimber [mailto:ekimber@reallysi.com] >> Sent: Thursday, February 24, 2011 3:35 PM >> To: Bruce Nevin (bnevin); Jonatan Lundin; Su-Laine Yeo; dita; >> dita-busdocs@lists.oasis-open.org >> Subject: [dita-busdocs] Re: [dita] RE: Vertical Industry >> Vocabulary in DITA 1.3 >> >> Then I would think that any such new base types identified >> through the BusDocs work would fall into my "fuzzy area" >> where we (the TC) have to decide if they're sufficiently >> general and useful to add to the core vocabulary. But nobody >> should feel they need to wait on that before proceeding with >> at least preliminary specialization design. >> >> That is, I think there are two distinct activities: >> >> 1. Designing new vocabularies that address specific use cases >> and communities of use. >> >> 2. Harvesting from those things that are sufficiently general >> and useful that they are appropriate for the base vocabulary. >> >> (1) should not need to wait on (2). >> >> And even very general things do not need to be in the base >> DITA vocabulary to be widely available and widely accepted, >> they just need to be widely accepted. >> >> Cheers, >> >> E. >> >> On 2/24/11 2:18 PM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote: >> >>> 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 >>>> >>>> >> >> -- >> 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_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]