> a. Relate via nesting
> b. Relate via reference
> b.1 Unidirectional (e.g. only from "container" to subflows)
> b.2. Bidirectional (from "container" to "subflow" and
> vice versa; corresponds to your sketch)
Good summary. And maybe the TC will come up with other variants.
One issue I see with the option a. is that the inline markup would have no way to know how many sub-flows are extracted without having to lookup the container structure.
> Unfortunately, I am not sure if b.1 would really capture
> that spirit of "represent mutual relationships".
No, it would not.
> Wrt. the referential representation I could also imagine
> the following variant:
> <source>This is an image: <ph id='1'><ph id='2'
> ctype="x-flow"/><ph id='3' ctype="x-flow"/></p>.</source>
I assume you meant "<ph id='1'/>" not "<ph id='1'>".
I see one issue with this representation: If one of sub-flows is deleted in the next version of the source document, the XLIFF markup of the parent flow has to have a different number of codes. That would decrease re-usability without a good reason.
> ... From my understanding, however, XLIFF so far was oriented
> towards the "Relate via nesting" option. Upon second thought -
> since I often prefer the "there is a general rule, and there
> is only one way for doing it" approach - I seem to lean towards a.
Possible good points. I think the idea is that at the inline markup level we could avoid to assume a specific representation of the sub-flows besides saying each one would be in its own "unit" (or whatever concept correspond to that in our definitions). This would allow for easier integration in various containers.
-ys
