xliff-inline — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
Teleconference - Sep-14-2010 - 13:30 UTC
Hi Yves, Forgive me for being a lurker instead of an active SC meeting participant. I am at fault for not attending the teleconference to discuss this in person. So please feel free to treat my comment as low priority. I guess I agree with the group's assessment that 17 is more suited to be a guiding principle, than a requirement (a better worded requirement would be "preserve the ability to represent well-formed inline wrapper tags in XML source as well-formed inline wrapper tags in XLIFF"). But I do not understand the language the group settled on for the guiding principle. I understand the first paragraph: "When processing the content with XML parsers, all the nodes of type TEXT should contain real text. This allows the separation between textual content and codes to be physical even in XML tree representation, rather than requiring interpretation of the markup." However this is different than the spirit of proposed requirement 17 (1.17 refers to the element node of (for example) ; 2.1 refers to the text node). In fact I begin to worry about this paragraph when the language implies that there is some kind of burden imposed by "requiring interpretation of markup." The gist of 17 is not that something like need to be interpreted as bold, or emphasis, but rather that the inline wrapper tag is preserved as an inline wrapper tag. No interpretation needed as far as I can see. I begin to lose track with the second paragraph: "For example, the imaginary representation below stores the native codes [startBold] and [endBold] as part of the content." It seems quite a bit abstracted from the example in 17: "This text is in bold" (in fact it seems to go out of its way to not be an XML example). After all the goal of 17 is to preserve the ability for inline elements to continue to be inline elements throughout the extraction and re composition of the XML --> XLIFF --> XML lifecycle. In short the guiding principle would be that an XSLT processer could process the inline element as an inline element for the trip back from XLIFF to XML (back to my drumbeat of "
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]