Re: [xliff-inline] Type of codes

[Arle Lommel <alommel@gala-global.org>]

Do we know what equivalent processing models are currently used by various tools? I don't know the internals on most of the tools, so I am asking out of curiosity/ignorance.

But my thought is that there is no sense in making a solution that is more elaborate than what most tools actually do. Part of the answer to this question should be based on how do we support what the tools do and need.

One of the problems with TMX 1.4b's metamarkup system, for example, is that it required (at the element level) for tools developers to provide information that they simply didn't have. So one tool might treat everything as <it> or <ph> simply because <bpt> and <ept> required more information than their filters provided.

-Arle


On Dec 7, 2011, at 08:29 , Estreen, Fredrik wrote:

> Hi Yves,
> 
> my vote on this is for B.
> 
> My main reason is that it will allow only one style of tagging. Also supporting <pc> which I agree is nicer from an XML perspective forces all implementations to support two completely different ways to represent the same tagging, spanning and non spanning. It also requires a transformation from <pc> to <sc>/<ec> to be defined in order to allow some cases of sub segmentation. So my argument is simplicity.
> 
> My second preference would be for D a single <ph> with attributes defining it's usage (given that it is only used non spanning). It provide the same functionality as B but in an in my opinion less clear way.
> 
> Regards,
> Fredrik Estreen
> 
> -----Original Message-----
> From: xliff-inline@lists.oasis-open.org [mailto:xliff-inline@lists.oasis-open.org] On Behalf Of Yves Savourel
> Sent: den 14 november 2011 17:31
> To: xliff-inline@lists.oasis-open.org
> Subject: [xliff-inline] Type of codes
> 
> Hi everyone,
> 
> One last summary on the type of codes discussion.
> I've listed below the four options we have:
> 
> 
> A) ph, pc, sc/ec
> 
> This is the current draft. We allow both pc and sc/ec, the second being used when the first cannot.
> The main advantage is that it offers the pc cleanness to users who need it.
> It has the drawback of making thing a bit more complex for the tools.
> 
> 
> B) ph, sc/ec
> 
> This would remove pc, marking all span-like original codes with sc/ec.
> It simplifies somehow the writing of the documents.
> Its main drawback is that not having a pc notation is not very friendly for XML-like original formats.
> 
> 
> C) ph, pc
> 
> This would change ph to handle also the sc/ec cases.
> This would add several attributes to ph. Essentially it would transfer the syntax of two element names to new attributes in ph.
> The pc element would stay to provide a clean markup for the well-formed span-like codes.
> 
> 
> D) ph
> 
> This would code all cases with ph: One code to rules them all.
> The ph element would have many attributes to handle all the cases.
> This option is especially attractive for tool extracting only placeholder codes.
> 
> 
> Note:
> 
> - Regardless of the option, we would still have a distinction between placeholder and span-like codes. In other words, even with option D (<ph> only) a filter should be able to extract an HTML <BR/> and a <B>...</B> making a distinction, for example: <ph id='1'>&lt;BR/></ph> and <ph id='2' kind='start'>&lt;B></ph>...<ph rid='2' kind='end'>&lt;/B></ph>. At some point we'll have to have a discussion about whether extraction tools MUST or only SHOULD do the distinction, but that's independent of the representation.
> 
> - Keep also <mrk> in mind. The presence of <pc> would make the use of <mrk> a bit more complex: (e.g. <mrk> overlapping <pc>). But not that much because <mrk> can overlap <mrk> too so the use case exist even if <pc> is not there.
> 
> 
> My personal opinion:
> 
> I think have distinct elements for original codes that are placeholder vs span-like is useful, even important. So I would not put everything into ph.
> 
> I would tend to think having the span-like codes handled only with sc/ec is fine. But looking at how v1.2 is used, the requirements we have for 2.0 and the feedback of the past months, I can see there are arguments for also having pc, and since the drawbacks of keeping pc are not that big I would. We just need to make sure it can be mapped transparently to sc/ec and conversely.
> 
> So I would pick option A.
> 
> 
> What would you pick and, as importantly, why? (so all can understand the rationale of the choice)
> 
> Cheers,
> -yves
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xliff-inline-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xliff-inline-help@lists.oasis-open.org
> 
>