1.13. Must be able to represent separately different flows of text and codes when, in the original format, they are mixed together

[Yves Savourel <ysavourel@enlaso.com>]

I don't think we've discussed this topic much yet.

Note that it is related to "1.14. Should be able to represent the mutual relationships between a nested flow of text and its parent" (I'll send a separate email for it).

It seems for 1.13 that we can see what not to do from the <sub> experience in XLIFF 1.2:

In XLIFF 1.2 one of the solutions for sub-flows was to represent them using <sub>. Here are some of the reasons I think we should not repeat that adventure in 2.0:

- Using <sub> inside the content of an inline code forces recursive processing (a <sub> can have inline codes, that can have <sub>, that can have inline codes, that can...)

- It forces one representation to be used (one cannot use <g>/<x/>, etc. with <sub>). In 2.0 it would be even more complex since we have two different ways to store the original data.

- It's bad for re-usability: An entry with a <sub> is basically two segments in one. This decreases the chances for exact matches. It also increases the word-count if one is changed because you have to edit both.

- We should try to have only one way to do one thing, that improves interoperability.

For those reasons I would strongly recommend to not go that direction in 2.0.

Which means we would go with the representation of each flow (main or sub) in separate text units. For example, given the following HTML code:

  <p>This is an image: <img title="Title text" src="image.png" alt="Alternate text"/>.</p>

We would have three flows: one main flow and two sub-flows. And we would represent them as three separate text units:

  <source>This is an image: <ph id='1'/>.</source>

  <source>Title text</source>

  <source>Alternate text</source>


So, am I close to a good solution or completely off with this?

-ys