Having structured content we can easily address into the content, which enables us to implement powerful features with linking.
A link consist of
- source and target anchors
- system and custom metadata
A link can have multiple source and target anchors, not just one on each end, but this up to the application.
An address to an anchor can consist of two parts:
- to an object
- into an object
Of course an object (document) can be a link anchor itself, but often we also address into the document to target a specific element, a section for example.
The simplest and likely the most robust way to address an element using an ID attribute. There are other methods also, like using the path expression how we get from the root element to the anchor element, but it’s not reliable when the content is changing all the time. Inserting a new section before our target could break the link.
It’s the best if we keep as little information about the link inside the content as possible during the editorial phase. It’s called independent linking.
Here the source anchor knows everything about the the target, which is probably necessary in the publishing stage, but might not give us great flexibility during the editorial phase. Just imagine we want to split o2 into multiple objects, but o1 is edited (locked) by someone else. Then we we should update the source anchor element attributes, modify the target-object value, but we cannot, since it’s locked.
Better if we use globally unique anchor ids and keep the rest of the link as external information:
System link metadata, link schema
A CMS usually identifies link types, which is a schema defines
- constraints, what anchors the given link type can have (restricting object types and anchor elements)
Custom link metadata
Not only documents / objects can have custom metadata but also links. This is defined by a project and it can implement business logic.
Links or more precisely link anchors belong to certain object versions. If I create a new object version from the current one, then the system “clones” the object, not only its content but its metadata and links also, because the new version - at the starting point - same as the last one. Then I start to modify it, maybe I do also delete link, but if I change my mind and want to roll back to the former version, then I should get to the former stage just exactly as it was. I also want my links back.
CMS must do link validation in order to keep links consistent. Many operations could potentially break links. It’s always a better idea to keep links valid all the time during the editorial phase than checking them during the publishing and trying to fix them then.
- The user wants to delete an object which has link anchors. The system can display an error and ask the users to check and delete the link first… or ask for confirmation if the links can also be deleted.
- The user checked out the document for editing, deletes a section which happen to have a link anchor. During check in the system should discover this and act according to the business rules.
Applications of linking
Links can be used for far more things than you would think first. Let’s list a few of them
- Hyperlinks - This is the most obvious use case what we use daily on the web: a text reference to an other page / text.
- Structure links - We can build whole structures using links. The simplest one is a “subdoc link”, a link between a master and a sub document. The source anchor is inside the master document, where the sub document will be assembled into on for example view, edit or export (publishing) operations. Obviously a sub document can also be a master at the same time referring to other sub documents. This way we can build up a complex structure (a “book” for ex.), where CMS content objects are called components.
- Variants - Objects or links can have metadata which defines their validity in calendar time. For example a statute’s paragraph can look differently in certain time periods. These are content variants, not versions. Links can help us to connect the variants and with validity metadata we get point of time functionality. We’ll be able to assemble the statute which was valid at any certain point of time
- Relations - We can model relations with links. If we have a content object which describes the product and an other one the producer, then we can link them with a “produced by” link. How will this be used then? Maybe the producer name is mentioned in the product description. Let’s assume the producer makes several products. When it rebrands (change name), then the CMS should populate this change to the product description documents. This way this relation link is used for dependency management.