The Glossary Package is based on the ACS 3.x glossary module which was simply a repository for a site's terms and their definitions.
In the process of migrating the glossary to an ACS 4.0 package, we will expand it's feature set to support multiple contexts. A site, subsite, group, user, or even document (a this point the document must exist in the database as an ACS object) may have one or more glossaries associated with it. Terms may have illustrations (acs-content-repository). Each glossary can have its security set (acs-permissions), a workflow, and optionally except user comments. A glossary's content will be stored in the content repository and its presentation will use the ArsDigita Templating System (ATS).
The Glossary Package does not provide a mechanism to expire content (glossaries or terms).
Glossaries provide excellent support for collaboration. Referring to terms' definitions can keep misunderstanding in check thus making it easier to work in groups.
The ArsDigita Content Management System is a more general interface to the content repository. With minor tweaking, the Glossary Package's data model can be used with it, but one would probably not want to use both UI's simultaneously (currently the effects are untested).
The original Glossary module was simple and very limited. There could only be one per site. It probably only took a matter of hours to implement.
With the move to a new platform, ACS 4.0, we gain from the system's base functionality. We take this opportunity to greatly expand the feature set of the Glossary.
There is also support in the data model for multiple languages. We hope multi-language support can be added in the future.
There are lots of glossaries on the Web, however, I was unable to find a website that used anything but static HTML files for glossaries.
By expanding the feature set, we greatly expand the complexity of the logic required to implement the package. Thankfully, most of this logic is held in the ACS platforms built in APIs and we simply have to tap them.
The biggest single trade off in the Glossary Package's design is having multiple glossaries per package instance. We lose potential flexibility in URL mapping of site nodes to single glossaries and some simplicity of administration. I feel this trade off is necessary until there is a standard for cross-instance sharing of data, i.e. I can see all the packages' glossaries that I have permission to see from one index.
I also decided to use specialized privileges in order to be able to grant a set of privileges to an admin easily and to tie into complex workflows more elegantly.
The Glossary Package is an application based on the Content Repository service package and the rest of the of ACS Kernel packages, as well as the Workflow and General-Comments packages. As such it inherits practically all of its API.
The Glossary Package Data Model is largely just creating custom content types (parent glossaries and their terms)for the Content Repository. We also create a relationship between the term content type and the image content type, we call this relationship an illustration. There are also some privileges and workflows created to tie into Permissions, General-Comments, and Workflow.
need to discuss attributes of objects and how the relate
We deviate from the normal user directory admin directory split and base a set of links and possible actions on the the user permissions on each of the object (glossaries, terms, and illustrations, as well as comments).
This is necessary to accommodate more sophisticated publishing workflows where there are several types of users whom have differently privileges on glossaries, terms, and illustrations.
Expect some fine tuning in this area between the alpha and the final release.
Before you instanciate a glossary package, you should instanciate a workflow and a general-comments package. Right now these must be at the same site-mode level and share similar permissions settings.
Some of these will be added before the final release.
Long range:
The revision history table below is for this template - modify it as needed for your actual design document.
| Document Revision # | Action Taken, Notes | When? | By Whom? |
|---|---|---|---|
| 0.1 | Creation | 11/21/2000 | Walter McGinnis |