XLIFF Inline Markup SC

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

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

Hi Bryan, > 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. Yes, this is certainly a lot to absorb for anyone who has not been following the progress. But I think we can make all this "digestible" if: a) we decompose it in smaller parts (Always going back to Descartes's Discourse of the Method, part II) for example: separate inline codes from annotations, permissions, added codes, etc. b) be very clear on what term we use and what they mean: I've noticed all committees have tendency to argue about the same thing: people agree but don't realize it because they use different terms for the same thing. b) as you noted, we also need to communicate better with the TC, and do this in advance. So no one is surprised by anything. Maybe I can try to summarize some of the themes where SC is more or less stable in recorded presentations with examples. This way anyone can watch that at leisure and even provide feedback to the SC. That may also help the SC: to be sure everyone is on the same page :) Cheers, -ys

Yves, this is great and very useful. I have been tied up with other things for some time and have not been able to keep up with the Inline SC work as I should, but that should change now. Since I've not been as active as desired, I am not entirely clear on some details, but my feedback may be useful because my eyes are somewhat fresh. A few comments: #1. In the discussion about sub-flows, I note the following: Note: the placeholder #2# is only an example of possible representation: 2.0 does not provide a standard way to represent sub-flows references in the original data. Is this just something we have yet to address or is it something we aren't planning on addressing? I'm not clear how to read this. I'm hoping that it is the former: that we just haven't solved this yet. In looking at this issue, I would argue that we need to define a standard way to represent these sub-flow references or we will end up in a situation where we have mutually incompatible ways of handling this. In other words, leaving this undefined will do exactly what XLIFF 2.0 is supposed to not do: leave things too loose. #2. I think that the document needs some explanation of changes that aren't transparent. For example, we have examples of <mrk> that are identical except for whether they use  mtype or  type . To the end user the motivation for a transformation from one to the others is not at all clear since the examples appear to be changes in attribute names only. In such cases where the motivation is not obvious, I think we need to document it carefully if the changes are not to appear capricious. Other examples where the changes could look capricious include: ctype  maps to  type equiv-text  maps to  equiv #3. Why the transition from  translate this but <mrk mtype= protected >do not translate this</mrk> to  translate this but <mrk type= trans translate= no >do not translate this</mrk> ? Without documentation, I'm wondering why something like this wouldn't work: translate this but <mrk translate= no >do not translate this</mrk> It would seem the important semantic bit is in the translate attribute (and this would correspond to the proposed translate attribute for HTML5). I'm not clear what type= trans adds here. I'm sure there is a reason, however. #4. In the “<mrk> with comment” section there is a minor error: He is my <mrk type= comment value This basically means 'alter-ego' ><mrk type= term >doppelgänger</mrk></mrk>. Should read He is my <mrk type= comment value = This basically means 'alter-ego' ><mrk type= term >doppelgänger</mrk></mrk>. Best, -Arle

Hi Arle, Thanks for going through the document. > Note: the placeholder "#2#" is only an example > of possible representation: 2.0 does not provide a > standard way to represent sub-flows references > in the original data. > > Is this just something we have yet to address or > is it something we aren't planning on addressing? It's the current state: we have touched on that question briefly when discussing sub-flows, but not reached a conclusion if/how it should be represented. So by default we don't have representation at this time. Now should we or not have a standard way to do this? I see the advantage in having a single way to represent it. But at the same time I see it big restrictions: defining how tools should represent original data may restrict them on what they can/want to do. Note that there is no obligation to have the original data, so the tools will have to be able to handle the case when no reference marker (standard or not) exists, anyway. Note also that if you assume the sub-flow reference has a standard representation, we need to assume the whole original data also need to have a standard representation: do we want to go that direction? Basically this is about have a standard way to represent the skeleton. Note also that sub-flows are not necessarily coming from inline codes. You can have for example an HTML title attribute in the start tag of <p> which is in the external skeleton and therefore may be invisible to the tools. > #2. I think that the document needs some explanation > of changes that aren't transparent. For example, we have > examples of <mrk> that are identical except for > whether they use mtype or type. To the end user the > motivation for a transformation from one to the others > is not at all clear since the examples appear to > be changes in attribute names only. In such cases > where the motivation is not obvious, I think we need > to document it carefully if the changes are not > to appear capricious. All the <mrk>-related parts in the table are currently incomplete since we are still working on how to represent those annotations. But I get your point: we need to provide explanation even if it seems logical to the user reading the whole document. In this specific case, we are simply consistent with the new markup. We'll have to decide of all names at some point. > #3. Why the transition from > translate this but <mrk mtype="protected">do not translate this</mrk> > to > translate this but <mrk type="trans" translate="no">do not translate this</mrk> > > Without documentation, I'm wondering why something like this wouldn't work: > > translate this but <mrk translate="no">do not translate this</mrk> That the current annotation mechanism: type is a required attribute. We may want to make exception for this case as translate is indeed an attribute that is not directly related to the other info of <mrk>, so type is not technically needed if that is the only info for that <mrk>. That is we can have: He is my <mrk type="term" translate="no">doppelgänger</mrk>. > #4. In the “<mrk> with comment” section there is a > minor error: > .. > He is my <mrk type="comment" value="This basically means > 'alter-ego'"><mrk type="term">doppelgänger</mrk></mrk>. Good catch. -ys