RE: [xliff-inline] Teleconference - Sep-13-2011 - Summary

[Yves Savourel <ysavourel@enlaso.com>]

XLIFF Inline Markup Subcommittee Teleconference - Summary

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


The summary of our main items is here:
http://wiki.oasis-open.org/xliff/OneContentModel/Requirements


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

We had the action item to propose some representation for the same example.
The original post is here:
http://lists.oasis-open.org/archives/xliff-inline/201108/msg00027.html
The mailing list has plenty of follow-up emails. Most of them have "Sample for metadata" in their title.

Careful to not mix purposes.
Having specific elements avoid that.
Maybe element for some aspects, attributes for others.
Generic markup for 'extensions'
-> elements an advantage from that viewpoint

Arle: It depends, in part, on how important the specific element is to you and what sophistication you need.
A generic markup wouldn't allow you to tune it as much to your needs as would specific elements.
It's similar to Andrew's comment.

If something is considered central, you may need more definition than a generic markup would allow.
But less central cases we may not want to define with that much specificity.

- translate (operation) attr-translate
- terms (classes) <term> (extra data, extra action)
- comments (classes) <comment> (extra data, extra action)
- generic span <mrk>

1.2: abbrev, equation, etc. <mrk mtype='sometype'>

Arle:  wouldn't make those elements. I'd take the TBX approach: <term type="xxx">
I wouldn't try to define all of these things.

Identifying spans vs adding info to a span.

Arle:  With terminology, there is a practical question: where does this term tagging get added?
Really only the most sophisticated processes are likely to handle this in a way that would require more than simple term tagging.
If you need that, maybe that's when you look at a namespace?
That's the approach with the old tbx-link, but it was never finalized.
My comment in writing about TBX-link wasn't clear:
I meant that what Yves outlined (pointers to external resources) is what TBX-Link was doing.

ACTION ITEM: Yves to provide new representation tries based on the discussion.



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

The last email I can see on this topic is:
http://lists.oasis-open.org/archives/xliff-inline/201108/msg00011.html
But I think Christian posted an answer. (could you confirm?)

It seem the last part of the solution here is to name the 'rid'/'refid'/'idref'/whatever that is the attribute in the closing element that points to the opening one. Naming can wait too.
Maybe use whatever+'Ref' for those referring ids.

Yves to check with Christian if this is ok to mark this item as Stable.


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

See http://lists.oasis-open.org/archives/xliff-inline/201108/msg00013.html
I don't think there has been any follow-up on this.

Arle: Seems the most reasonable and straight-forward to handle this issue (referring to flows).
1.2 <sub> is recursive.
Arle: The pointer idea flattens the recursion. A good thing overall.

About need for a unit to 'stand alone'?
Reference to another unit may not break that principle.
May cause problem for streaming process.
Should we 'force' an order?
-> probably not.

Arle: From a translation perspective the order might logically be in almost any order.
In some cases you might need to know the subflow to translate the main section and vice versa.
I wouldn't mandate an order. Instead just note that you need to have access to *all* of the referenced flows before moving along.

-> so agreement: order should not matter.

This can be marked as stable.


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

See http://lists.oasis-open.org/archives/xliff-inline/201108/msg00022.html
And before/after
I've detached the discussion about the id values in a separate topic

Should 2 sub-flows be referred from 2 codes or one.

Arle: Would there be cases where you might end up splitting the two items?
I can't think of anything right off, but might it be possible?

Solution: an attribute in the inline code with a list of IDs to the units of the sub-flows.
(e.g. subFlows='1 2')

Case of the re-creation of the tag. Should we have a defined way of marking the skeleton for the reference.

<ph id='1'>&lt;img title='$1$' alt='$2$'/></ph>

Would it be a special case of the skeleton? (sub-segment level)

David: Having or not the original data make interoperability more difficult.

-> remaining issues: a) should we define the skeleton for this?
b) relationship from child unit to parent to be decided in container format.


=== 1.16. Inline codes should have a way to store information about the effect on the segmentation

See http://lists.oasis-open.org/archives/xliff-inline/201109/msg00005.html

Skipped today. Please use the mailing list to discuss it.


=== ID values.

Several of our constructs call for ID values.
We need to define what value are OK for an ID, and it needs to be compatible with what the TC will do as well.

See http://lists.oasis-open.org/archives/xliff-inline/201108/msg00025.html

Skipped today. Please use the mailing list to discuss it.


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

On this topic we are actually discussing wording of the text of the solution rather that what solution it should be.
See http://lists.oasis-open.org/archives/xliff-inline/201109/msg00003.html

Allow or not valid char in cp?
Arle, Andrew: “Be conservative in what you send; be liberal in what you accept.”

What about error handling?
-> Dangerous ground.

Arle: You can't mandate someone to identify all errors. Some might be fatal, but others you
could go past to give a lot of information.
But that's up to the implementer and the methods they use.


=== Any other business

Yves wondered about moving the time one hour later (to make it easier for some).

-end




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php