Author Topic: Glossary matching options  (Read 7130 times)

qwerty

  • EA Guru
  • *****
  • Posts: 11334
  • Karma: +291/-262
  • I'm no guru at all
    • View Profile
Re: Glossary matching options
« Reply #15 on: July 31, 2019, 08:22:25 am »
I'd do as Eve suggested. EA has (I mentioned that elsewhere) which are half baked. A sales disease. Anyhow, I once modeled my own glossary which also had the capability to be multi-lingual (a feature which tends to bite back where you don't expect it, so better not to be really used). But having <term> and <definition> lets you create your own glossary at the end of a document (at least if you use your own document generator like me). Admittedly, it would be smart to see EA offering such a generic way rather than that home brew glossary. Finally attaching that highlighting mechanism would have been really smart. UML is such a nice language. But well...

q.

timoc

  • EA User
  • **
  • Posts: 143
  • Karma: +8/-0
    • View Profile
Re: Glossary matching options
« Reply #16 on: August 03, 2019, 08:10:06 pm »
The limiting factor for extending the built-in glossary functions is really the database structure in place.

Even with that, I think it makes a lot more sense to model your glossary than to use our glossary list. I would encourage you to implement your ideas as a profile. The management of it is then integrated with all the rest of EA functions (eg. version control, searching, reporting) you get traceability between terms etc.

Once you have that in place I see potential for an add-in to help manage a profile glossary. I can also imagine automation/scripting broadcasts to determine what should be highlighted, how to display a tooltip etc. A flexible solution like that is going to serve the needs of the community much better than any predefined glossary structure defined here.
Can i ask why there is a limitation with regards to database structure changes?

timoc

  • EA User
  • **
  • Posts: 143
  • Karma: +8/-0
    • View Profile
Re: Glossary matching options
« Reply #17 on: August 03, 2019, 10:30:13 pm »
My 2eurocent on the topic.

I had a different idea which i submitted to sparx about about the glossary feature - essentially extending the 'glossary' to a 'generic link' style, like you might see in a wiki. That way you make all of a model addressable from the text, and can define the word in the visual context of a diagram.

The implementation of the idea i had in mind, which should not require database changes per-se, is essentially using a regular expression to match to an EA URI type link.  e.g. "/matchthis/EA-uri:link/". This idea can solve these other issues by allowing yoiu to explicitly match to the correct glossary item with "/pluralmatch/glossary-uri:singluar link/'.