Proposal: interrim representation of "beta" story components

[adgad]

Problem

We're introducing a new pathway to building "core" content components, as a "beta" component. These components will be defined in Content Tree, and published as a part of the tree, but:
a) will be subject to change during development/iteration
b) will have an automatically-generated storyblock UI in Spark
c) may not have a content-tree -> bodyHTML representation yet, until finalised

We are almost ready to start exploring this idea and process, however we are not yet in a position to publish and render FT.com content using bodyTree yet.

Proposal

In the short term, Spark can publish these beta components with the following XML representation:

<experimental>
   <content-tree-node node='{"type": "my-beta-thing", "title": "Beta Title", children: [{ "type": "paragraph", "children": [...] }]'></content-tree-node>
</experimental>

In cp-content-pipeline-api:
content-tree-node nodes are tagMapped to extract the JSON from the attribute, and insert into the tree

In cp-content-pipeline-ui:
The UI component is built as normal.

Migration to content-tree

When we are ready to publish with content-tree:

• The UI component works as it does and should not require changes
• We can remove the content-tree-node mapping from cp-content-pipeline-api
• EITHER in the Go bodyXML->bodyTree transformer, we map content-tree-node to be the node
• OR we republish the content from Spark

Benefits

• We're able to test the concept of beta components and get things in front of users quicker
• It's not a huge amount of work for Spark / CP
• By passing the content-tree representation, we don't have to worry about making an XML representation for everything
• It's easily removable once we don't need it, and doesn't require rebuilding our components

Limitations

• This will NOT work with images, clips or any related nodes (basically, anything in content-tree that has an external field)
• In this phase, the components will not be available to external clients. This is no worse than the current situation (where they would likely be built as CCCs), and there is a pathway to making them available once we're publishing content-tree
• We should probably make sure the components are not used 100s of times in the next few months.

Alternatives

1. Do Nothing: this means we have to wait potentially several months, before being able to test and validate the concept of beta components. Whilst we are still prioritising this work, it's not something we want to rush in order to appease editorial's desire for new features.

2. Represent children as XML children e.g.:

<experimental>
   <content-tree-node node='{"type": "my-beta-node", "title": "my title"}'>
      <content-tree-node node='{"type": "paragraph"}'>....</content-tree-node>
   </content-tree-node>
</experimental>

I think this will get more complicated when we think of things like phrasing etc, and maybe makes the mapping to/from harder

3. Same idea, but not <experimental>
   We could do this, but I'm not sure if there's any benefit? It's not going to be made available externally anyway, and we will avoid nesting media (which is the main downside of )

[umbobabo]

Second Alternative

(Assuming there won't be any external reference in the Node and the audio source will be at this stage just a string)
Use a CCC for the bodyXML version.
Can Spark do the following?

• Publish the Content Tree in the BodyTree
• Publish a CCC with munged data in the BodyXML (The CCC may be the existing one or a slightly modified version if we need to adapt for a changed model)

In both solutions, I suspect the element will not be really useful to consumers.

FYI @elpopova

[epavlova]

I think it would be helpful for us to reconnect on the overall direction of the Content Tree initiative and the timelines for its adoption. I wasn’t aware that the adoption might be delayed by several months — my understanding from earlier discussions was that we planned to begin using the content tree and new components at the start of 2026, and that has informed our current timelines.

The content team has invested a significant amount of time in this project with the expectation that it would help address the degraded experience currently affecting a large portion of our content consumers (while also enabling faster development of new components). We were able to allocate this effort on the basis that it would lead to improved content sharing across all channels. The end goal has been to ensure that all components - regardless of their lifecycle - are properly represented across every format in which the content platform distributes content.

For transparency, Specialist US are already publishing using the content tree on Staging, and we are preparing the C&M platform to support content tree-only publishing.

All that being said, both the original proposal and Umberto’s second alternative are technically feasible, though they introduce additional complexity in managing transformations between two formats and would delay the content tree work. Still, this work is doable.

My suggestion would be to establish a shared timeline - outlining when the Content Tree API will be adopted, when new components will be created, and when publishing via bodyXML will be discontinued - before committing to interim workarounds.