OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-inline message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xliff-inline] v1.2 to v2.0 mapping


Wow! Let me see if I can rephrase that, Wow!

This is lot of work. And I can see the amount of work left to do is not small. Great job on this Yves and SC.

Seeing this in its entirety makes me think about the task of communicating the inline SC deliverable to the TC. The work is so massive, so important, and maybe so different than 1.2, that I think we as an SC need to be thinking of best ways to communicate, and fold this into the larger TC spec.

Forgive me if I'm talking in circles. I think there are many TC members who maybe have not been following, who will be overwhelmed. For sure, the regular reports, and posts to the TC have helped a lot. But perhaps we should start to think in terms of communication planning to make sure the entire TC is able to understand, and be in a position to articulate their reactions.

- Bryan

-----Original Message-----
From: xliff-inline@lists.oasis-open.org [mailto:xliff-inline@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Monday, October 31, 2011 10:04 AM
To: xliff-inline@lists.oasis-open.org
Subject: [xliff-inline] v1.2 to v2.0 mapping

Hi all,

Fredrik and I have worked a bit on the table of correspondence between the inline markup in v1.2 and v2.0. You can see that in the latest revision of the draft here:

http://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/inline-markup/inlineMarkupWorkingDraft.html

(click the Download button at the top to get it in your browser as real HTML)

It's by no mean final or complete, if you see any missing construct or some incorrect description or mapping, we need to talk about it.

The table helps highlighting a few things.

- As Fredrik already pointed out, we need an attribute in <sc>/<ec> to indicate 'islolated' code (opening or closing code without it corresponding closing or opening one in the same unit. We would also need to add an optional id to <ec> and make rid optional and change the description.

- Do we need something equivalent to the crc attribute? (I've never seen it used in the many TMX files I've opened since it has been there). 

- Do we need something similar to the assoc attribute? Does anyone using this? Should it affect segmentation? If yes, how that works with SRX options about tag handing?

- The clone attribute should be handled by our 'hints' information. We need to continue that discussion.

Cheers,
-ys



---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]