Differences between Indexing Engine v1 and v2

We require customers to move on to Indexing Engine v2. The requirements are indexed slightly differently. This page summarizes the XHTML / storage format differences between the two indexations.

See Choosing the indexing engine for the intrinsic qualities of this engine.

Note for Vertical Tables: The comparison tool will show the differences in dependencies, but it will not apply them (see “Vertical tables”).

Tables and lists

We don’t flatten lists and tables anymore.

Bug scenario: None expected, this one will only make the users happier

The storage data differences

The visual differences

Only the second column is used for the description

We only use the first cell as the body of the requirement. All the other cells are stored as properties, and the text of properties is not repeated in the cells.

The red part hasn’t been deleted, it is present in the properties (see table 2)

The requirement’s table (table 2)

When the requirement is in the second column (see table 3), the description is still extracted from the second column and is empty. But all columns are still extracted as properties, as before
(the property First column = “PPP”).

The requirement’s table (table 3)

Bug scenario 1: If your requirement key is not in the first column, or if your second column doesn’t contain the requirement description, then your requirement will have no excerpt and all text will be in various properties.

Bug scenario 2: When comparing requirements, you will notice there is less text in the description. This is because we don’t repeat the text of properties in the description. In our customer trials, surprisingly, most customers didn’t even notice and not a single question was raised. It is very visible during the comparison, but it seems more usable on a day-to-day basis.

Workaround: If you really need all columns in your descriptions, then you will have to put an RY Property macro in each necessary column (tick: “✓ Title”).

Rationale: Users didn’t understand why the same text was repeated in the description and properties. In most cases, the description of the requirement is indeed in the 2nd column, and in other situations, the RY Property macro can be used.

Links

We store the link’s relative URL:

The differences in indexation

The original table

Bug scenario: You query the Requirement Yogi REST API programmatically to display those requirements in your own software.

Workaround: You will have to render those links in your own software (That’s what we do in Jira).

Rationale: It is more future-proof when you change the URL of Confluence, which happens for all our customers who have a merger-acquisition.

Images

We save a lot more attributes, and we save relative links (as explained in the previous paragraph about relative URLs)

Bug scenario: None specific. It’s just a lot more data to save, and if image metadata changes often, it could look as modified between two baselines of the same requirement.

Rationale: Customers complained that we reformatted documents in v1, and images were reduced to their minimum, so we store the image as rendered by Confluence.

Vertical tables and parent/child dependencies

In Indexing V1, we used to create automatic parent/child dependencies between vertical tables and the following requirements.

Bug scenario: The comparison tool doesn’t show the differences, and upgrading those requirements doesn’t change their dependencies, but the next time they are indexed, dependencies will have changed.

Workaround: You will have to update your tables like this:

How tables must be written if you want dependencies between those requirements

Rationale: Some customers would like to make other uses of the “parent” dependencies and this automatic dependency was disturbing to them. However, removing this system brought controversy, so we might reinstate it later.

Scaffolding

Configurations are varied, so please report any difference that is affecting your business.

Some Scaffolding arrangements are not supported when they contain requirement definitions:

Recursive macros,
Repeat macros,
Excerpt/include macros with definitions: They will appear as duplicate definitions if they appear on several pages.

There is extra HTML added to my requirements

We save more HTML than before, and it sometimes leads to HTML such as div class=”content-wrapper”> to be inserted:

Bug scenario: None. The rendered content is the same and it just occupies more space in a database.

Rationale: We ackowledge those elements are visually polluting. However, there are added by Confluence and we have technical difficulties identifying them using a streaming parser (it would be easy using a DOM parser, but we try not to load the full XML of pages in RAM). Since they don’t cause issues, we don’t consider it a bug when they are present.

Requirement Yogi (Data Center)