1.14. Should be able to represent the mutual relationships between a nested flow of text and its parent

[Yves Savourel <ysavourel@enlaso.com>]

Here are a few thoughts on this topic, based on the proposal for 1.13 (here: )

I think the relationship between main flow and sub-flow could be done with attributes.

Note that while we can provide one for the parent to point to the children, we (the SC) cannot define one in the children to point to the parent because we don't control how the "text unit" is represented. But we can make some kind of recommendation.

So, still using this HTML code as the original source:

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

We would have something like this:

  <unit id='1' parent='3'>
   <source>Title text</source>
  </unit>
  <unit id='2' parent='3'>
   <source>Alternate text</source>
  </unit>
  <unit id='3'>
   <source>This is an image: <ph id='1' subFlows='1 2'/>.</source>
  </unit>

Notes:

-- This is just an example. It is for the TC to decide how the children and parent should be "grouped". For example, another possibility would be to use a <group> inside the <unit> of the parent, etc. The SC can only state general requirements. I think it's also important to make sure we state those requirement without assuming or implying the container format for the inline markup is necessarily XLIFF 2.0. One of the goals is to have a markup possibly re-usable outside XLIFF.

-- The attribute pointing to the children (here named subFlows) must be able to point to several of them. This implies certain restriction on the value of the text unit id. We have to provide a minimal requirement. I'm assuming NMTOKEN (http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken) so the subFlows value can be of type NMTOKENS.

-- Should subFlows be optional or not? The requirement is that we should have a way to represent the relationship, now we have to decide if that relationship must always be stated or if it's optional.

That's all I have for now.

-ys