[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff-inline] Type of codes
Hi Yves, I vote for A). Rationale: Even though in my personal workload I convert the occasional non-XML code into XLIFF and back (i.e., firmware, proprietary UI code for our instruments, RTF, Interleaf proprietary markup, Framemaker, etc.), it is becoming increasingly clear that most non-XML conversions can/do have XML alternatives. Upshot: excluding the XML friendly <pc> option, and forcing well-formed XML to use the (my opinion, sorry if it's harsh) hackish <sc>/<ec> approach, in the name of simplification, is very much not attractive. Similarly, to exclude the <sc>/<ec> seems to me to be a not attractive option. In real life there are cases where segmentation causes inlines to be separated (start and end tags). I see overloading the <pc> or <ph> with attributes to handle this case (while perfectly logical from an XML processing point of view) to lack clarity. Please feel let me know if I should provide details or examples. Bryan -----Original Message----- From: xliff-inline@lists.oasis-open.org [mailto:xliff-inline@lists.oasis-open.org] On Behalf Of Yves Savourel Sent: Monday, November 14, 2011 8:31 AM 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'><BR/></ph> and <ph id='2' kind='start'><B></ph>...<ph rid='2' kind='end'></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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]