I've been chipping away at this neverending subject of links, and I'm finding it to be pretty slippery, inasmuch as it combines concepts from filesystems, document management, software architecture, and also needs to account for workflow issues. In order to make some incremental progress, maybe it would help to gather together some representative use cases. A couple are included below. Summary: -------- Two representative cases are included: one of simple crossreferencing, illustrating linking between like elements with inheritance and override, as suggested by Alexander; and the other, a bit more complicated, considering links among heterogeneous elements and involving role specialization (editor and coder). A generalization of the idea of groups might be a solution to the latter case. Overview: --------- It seems as though links are largely about the separation of the roles of coder and editor. You want an editor to be able to configure content through a simple (preferably mostly point-and-click) administrative interface that allows him/her to configure content for display without having to involve the coder. Links should allow an editor to leverage code by setting up relationships among elements that are interpreted by preconfigured display code without having to modify the linked elements themselves. Ideally the editor should also be able to make simple changes to HTML markup and be able to readily finger the relevant code so that the coder can quickly determine exactly what needs to be modified if changes are required. Case #1: -------- Scenario: --------- An online magazine publishes a news article about a flood under the topic 'natural disasters'. The article also appears under 'News of the day'. It's the main story of the day and editor wants to display it as the lead item on the main page. Implementation: -------------- Here's a typical example of crossreferencing: you want to include an element in a second context without removing it from its original context. So you create an element of the same type in the second context and link it to the original; e.g., in this case create article B in one topic linked to article A in another. The second (extension?) article B inherits the properties of article A, but the fields in article B can be set to override the values of the fields of article A; similarly, an article C might be created that inherits the properties of B as B inherits them from A. In the example, article A is created under a 'natural disasters' topic and article B is created under 'News of the day'. Articles in 'News of the day' are sorted by score, so to display B as the first article, the score field is set 0, overriding the score field of article A. All other fields in B are designated undefined so they inherit the field values from A. CASE #2: Scenario: --------- An article is published in an annual review about year 2001 graduation ceremonies at a university. In the context of graduation, students for each class are cast in various roles (valedictorian, class president, winners of various awards, etc.) In addition, the article is published in full and summary versions, requiring different display formats for the various components. Implementation: --------------- This is a special case that's already reasonably easy to implement in Midgard, since Midgard already supports groups, and groups allow you to link person records via a members list. So an editor might create a group for each class and also groups for each role. For example, the valedictorian might be under both the 'Class N' group and the 'Valedictorians' group. It's straightforward for the coder to set up a routine to find the relationships using standard Midgard functions. There are some limitations to this, however. You have to create new groups for each association at the same hierarchical level as the Class groups, making management of the group records difficult. Also, the display code for each role is contained within the article or in a style element, with no built-in connection to the group or person records. Most likely the editor would need to enlist the help of the coder to locate and revise the appropriate display code. But now let's say the idea of group is generalized, so that a group is a collection of named links to any kind of Midgard element, and includes also some prototype administration and display code. This code specifies the link nodes available for the particular group. So the administration code for a 'Class' class group might call for links to person records for each class member. Another 'Class Graduation Group' might be created which has a link to the 'Class' group (so inherits the links to the class members in this group) as well as links to individual person records; one 'Valedictorian' link, one 'Class President' link, etc. The group might also includes links to style elements to display the content of the person records for each role. The admin interface allows the editor to create an instance of the 'Graduating Class' group, and requests links to an instance of the 'Class' group (that the editor might not have permission to modify) and also to person record and display elements for the defined roles. The 'Graduating Class' group is referenced within the article, and on command (something like 'execute group display'), runs display code that lists the linked elements and generates the appropriate HTML. To present the material in summary format, another group, linked to the first, might be created. This group inherits all the properties of the 'Graduating Class' but has display code that overrides the display code of the linked group. The advantage of this approach is that the groups would act as the binding agent for style and content. Although separation of style and content is considered to be a virtue, it's not an advantage to an editor if they are disconnected completely. The editor needs to be able to integrate content and presentation, but shouldn't necessarily have the authority to alter the elements of either. Generalized groups would allow the various Midgard elements to be linked in such a way that the relationships among them can be readily identified. This might be better from a workflow point of view than simply allowing links to be made directly between arbitrary elements. Paul N. http://www.commentext.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
