RE: [xliff-inline] XLIFF inline markup - Teleconference - Aug-09-2011

[Yves Savourel <ysavourel@enlaso.com>]

XLIFF Inline Markup Subcommittee Teleconference - Summary

Presents: Yves, David-W, Christian
Regrets: Arle, Andrew

See requirements list:
http://wiki.oasis-open.org/xliff/OneContentModel/Requirements


=== Checking stable entries.

I've listed several entries as "stable"
It means: we've discuss them and came up with a solution that, as far as I can tell, is fine to all.
(we'll revisit element names at the end)

It would be good if, as preparation work, we could go through the list of stable entries and see if you are ok with it. If not, please, edit the wiki to change the label and list the points you think we still need to discuss.

-> No one had currently any issue with the item listed as stable.



=== Items "under discussions"


--- 1.3. Must be able to represent paired codes that have been separated

Discussion summary: using one id-reference attribute seems good.
Important to have the id accessible for the whole unit (not just the segment)
Name of the attribute: still discussed but since naming things is a on-going discussion not altering the feature we'll mark this item as stable.


--- 1.5. Must allow to associate spans of content with metadata

David, Yves: Using a generic markup seems more flexible.
May nee use-cases with specific values to understand better the implications.

Some questions:

Some <mrk notrans='yes'><mrk term='true'>text</mrk></mrk> in the content

Vs.

Some <mrk notrans='yes' term='true'>text</mrk> in the content

Vs.

Some <mrk type='notrans'>text</mrk> in the content (then one type per mrk)

Vs.

Some <mrk annote="notrans:yes, term:yes">text</mrk> in the content (CSS-like)


ACTION ITEM: Yves to provide example text to markup and all to come up with solutions.


- ITS: Christian: Not sure yet how to handle this.
Yves, David: either use the namespace for all or not (and implement the datacat) may be better



--- 1.8. Must be able to identify uniquely an inline code within a segment

- ID value: Hard to follow xml:id constraints
Christian: see the need for some restriction of the value set, otherwise leads to space problems, or non-ascii issues, etc.
There are benefits to restrict. But it may make the creation of ids harder.



--- 1.12.3. to store a pointer to it along with its XLIFF representation

Besides the name, things look fine for now.
Change the status to stable.


--- 1.15. Should be able to represent illegal XML characters in the content

David: can we use e.g. "&#001a;"?
Yves: alas no, it's also invalid. (will double-check)
Christian: may be something like: <cp hex='001a'/> e.g. LDML (IBM)
Yves, David: looks fine.


--- 1.14: sub:

Christian: A bit like withinText, but richer.
Something moved out of context (detached from the container element).

Rewording the requirement: "The markup should be able to allow nested flows/subflows to be represented as stand-alone text units. The markup should be able to represent the mutual relationships between a nested flow of text and its parent"

CSS-type representation: <ph ctype='image' subFlows="alt:1; title:2"/>



=== Draft

Waiting for the docbook template we can use.
Can wait as we have plenty to do.


=== Any Other Business

None.

-done