Tagging granularity and LSCS document retrieval

cecilb63

This questions involves the tagging of documents and retrieving them through LSCS REST API using TS/LS 7.2.1. We have been using LSCS in production for about a year and have very good familiarity with TeamSite/Workflow/FormsPub/SitePub/LSCS/LSDS.

We have requirements where low level content items, such as links or text strings, require individual tagging to allow filtering to occur via content targeting. This requires the links to be authored in a single DCR so the link document can be tagged and then appropriately accessible through the LSCS REST api. This arrangement is an issue for the authors because they have to create a new DCR for every link (so it can be individually tagged) when they’d rather author content in a more meaningful way, such as logical groups of items in one DCR.

One solution might be to add attributes to the DCR that provide the metadata information needed to filter the links. That way the authors could create a single DCR with all the related information (say for a particular widget) and tag each item as needed for filtering. But this requires custom processing after document retrieval to then go through all the items and see which should be filtered out. This processing is not desirable and contrary to how LSCS works.

It seems to me, how content is authored shouldn’t necessarily tie directly to which documents are then available as result set items from an LSCS query.

What I’d rather see is a content group document split apart at publish time into individual documents for each item, all with their own specific tags, so then we can retrieve content from LSCS as it meant to be used. But this raises issues with managing these “dynamic” documents: how would they be deleted, etc.


Has anyone else puzzled over this situation? Any good ideas or solution? Is there something in the underlying IDOL which addresses this scenario?

Rick Poulin

It sounds to me like your requirements have gone beyond LSCS's capabilities, and you're now looking at a full RDBMS. If you have a fixed number of items per DCR (i.e. no replicants to map as LSCS fields), then you can use the PLC's configs to map fields within your DCR straight to EAs. Still, it sounds like it would be a very limiting approach and may not fully satisfy your needs.

If you're going to stick with LSCS, I think your only alternative to splitting your content into smaller DCR chunks is to build a workflow task that reads attached DCRs and creates XML fragments (or even empty .txt files) for each document you want to insert into LSCS, setting EAs and content as required. Then, you just need to figure out how to manage deletions of those fragments when necessary.