RE: [dita] use of <term>

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

> the standard is law, what Bruce has 
> presented is interpretation. They are both important but they 
> belong in different documents.

Does the interpretation/recommendation document exist?

Glad to know that application is so easy. Must be some other reason no vendor has responded to that requirement statement by saying "Oh yes, we do that out of the box."

	/Bruce 

> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com] 
> Sent: Thursday, March 12, 2009 1:53 PM
> To: Bruce Nevin (bnevin); Christian Kravogel; Alan Houser; dita
> Subject: Re: [dita] use of <term>
> 
> Not to be flippant, but I would see the requirement Bruce 
> outlines as being obvious to the implementor of any 
> DITA-aware CMS or custom publishing system vendor.
> 
> I don't think it's the place of the spec to talk about 
> general requirements for how to manage and author DITA 
> content--that's simply too open-ended. But that seems like 
> exactly the role of the DITA Adoption TC--to clearly 
> articulate requirements like this one.
> 
> The DITA spec needs to focus on the facts of what it says 
> about the markup and direct processing expectations and 
> requirements. General how-to information and general "you 
> could do X" or "X would be really helpful" is simply not 
> appropriate for a standard.
> 
> Or said another way, the standard is law, what Bruce has 
> presented is interpretation. They are both important but they 
> belong in different documents.
> 
> Cheers,
> 
> Eliot
> 
> On 3/12/09 10:45 AM, "Bruce Nevin (bnevin)" <bnevin@cisco.com> wrote:
> 
> > I see no harm in the spec giving indications to vendors as to what 
> > they should be developing.
> >  
> > This is an important function that's been in my 
> requirements doc for 
> > six years or more, with no vendor supporting it. Process as 
> follows: 
> > Writer marks an item in a topic with <term>. Processing 
> harvests every 
> > <term> in all the topics in a map (or other aggregation). 
> If a given 
> > <term>-tagged item also appears in an associated glossary document 
> > (associated in the publishing environment), it is included in a 
> > glossary for the publication that is assembled and 
> published as part 
> > of that document, and appropriately linked in online 
> renditions. If a 
> > given <term>-tagged item does not appear in the glossary, a flag is 
> > raised for someone to create a glossary entry for it, and 
> until then 
> > that item is not rendered as a glossary item (link, etc.) 
> or in any special way.
> >  
> > At present, glossaries are labor intensive, error prone, and often 
> > omitted although desired.
> >  
> > This is an example of how use cases may not be being 
> communicated to 
> > vendors, and the spec can help close that loop. Relevance 
> to adoption is obvious.
> >  
> >     /B
> > 
> > 
> > ________________________________
> > 
> > From: Christian Kravogel [mailto:christian.kravogel@seicodyne.ch]
> > Sent: Thursday, March 12, 2009 11:49 AM
> > To: 'Alan Houser'; 'dita'
> > Subject: AW: [dita] use of <term>
> > 
> > 
> > I pretty much like working with xquery and the idea that 
> this problem 
> > should be left to impementers or actually be solved by the 
> stylesheet. 
> > But I am not sure if that is reliable with all languages 
> and character sets.
> > 
> > Regardless if that task can be solved by implementers in 
> all cases, we 
> > should not generate expectations to future DITA 
> implementations in the 
> > langref over a period of 3 DITA releases.
> > 
> > Either we should provide associative linking to matching glossary 
> > entries as it is mentioned in the langref, or we mention that the 
> > implementer can link the <term> with the corresponding 
> <glossterm> via 
> > stylesheet i.e. xquery.
> > 
> > I do not propose "deleting" but "giving unambiguous 
> descriptions who 
> > do not create expectations we may not going to fullfill"
> > 
> > Best regards
> > 
> > Chris
> > 
> > 
> > 
> > 
> > 
> > SeicoDyne GmbH
> > Eichenstrasse 16
> > CH-6015 Reussbühl
> > Switzerland
> > Tel: +41 41 534 66 97
> > Mob: +41 78 790 66 97
> > Skype: seicodyne
> > 
> > www.seicodyne.com <blocked::http://www.seicodyne.com/>
> > christian.kravogel@seicodyne.com
> > <blocked::mailto:christian.kravogel@seicodyne.com>
> > 
> > 
> > 
> > 
> > 
> > 
> > Member of the DITA Technical Committee Chairman of the DITA Machine 
> > Industry Subcommittee
> > 
> > 
> > ________________________________
> > 
> > Von: Alan Houser [mailto:arh@groupwellesley.com]
> > Gesendet: Donnerstag, 12. März 2009 16:32
> > An: Christian Kravogel
> > Cc: 'dita'
> > Betreff: Re: [dita] use of <term>
> > 
> > 
> > I recall that there was a semantic linking feature on the table for 
> > DITA 1.1, which may have been associated with the <term> element. I 
> > believe it died more to lack of inertia than anything else.
> > 
> > I would concur with Paul Grosso's assessment that this would be 
> > application behavior, best left to implementers.
> > 
> > -Alan
> > ---
> > 
> > Alan Houser, President
> > Group Wellesley, Inc.
> > 412-363-3481
> > www.groupwellesley.com
> > 
> > 
> > Christian Kravogel wrote:
> > 
> > I have just checked the langref of the element <term> in 
> version 1.0, 
> > 1.1 and 1.2. All langref descriptions are identically with 
> the following sentance:
> > 
> > The <term> element identifies words that represent extended 
> > definitions or explanations. In future development of DITA, for 
> > example, terms might provide associative linking to 
> matching glossary entries.
> > 
> > As "future development of DITA" is mentioned within 3 DITA 
> releases we 
> > may have either to change this text or to provide a 
> solution. Or do we 
> > already have solved this, then we may have to update the text.
> > 
> > Best regards
> > 
> > Chris
> > 
> > 
> > 
> > 
> > SeicoDyne GmbH
> > Eichenstrasse 16
> > CH-6015 Reussbühl
> > Switzerland
> > Tel: +41 41 534 66 97
> > Mob: +41 78 790 66 97
> > Skype: seicodyne
> > 
> > www.seicodyne.com <blocked::http://www.seicodyne.com/>
> > christian.kravogel@seicodyne.com
> > <blocked::mailto:christian.kravogel@seicodyne.com>
> > 
> > 
> > 
> > 
> > 
> > 
> > Member of the DITA Technical Committee Chairman of the DITA Machine 
> > Industry Subcommittee
> > 
> > 
> 
> ----
> Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
> email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of 
> the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com 
> <http://www.reallysi.com>  | http://blog.reallysi.com 
> <http://blog.reallysi.com> | www.rsuitecms.com 
> <http://www.rsuitecms.com> 
> 
>