RE: [xliff-inline] Teleconference - Sep-14-2010 - 13:30 UTC - Summary

[Yves Savourel <ysavourel@translate.com>]

Hi Bryan,

> 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").

Actually I already disagree :)

The GP-#1 (which was Req-#17 until today's meeting) has nothing to do with preserving well-formness. It just means to say that it would be nice if we put only real text in XML TEXT nodes and codes (paired or not, well-formed or not) outside TEXT nodes.



>... However this is different than the spirit of proposed 
> requirement 17 (1.17 refers to the element node of (for example)
> <b>; 2.1 refers to the text node).

I assume the Req-#17 you mention above is the one that was Req-#18 before today.
We have not looked at that last requirement during the call.
So it may or may not contradict GP-#1: that has not been discussed at all.



> 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."

From the viewpoint of GP-#1 we only say: It's better to have text on TEXT node because otherwise you would have to look at the elements (interpret the markup) to know if the content of any given TEXT node is real text, or the original data of an inline code.

For example in XLIFF 1.2: <source>A<ph id='1'>B</ph>C</source>
We have 3 TEXT nodes: 'A', 'B', and 'C'
There is no way to know 'B' is code data and not real text without looking at its parent.

The guiding principle simply says: if we could find a notation that avoid this, it would be great.


> 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 <b>bold</b>" (in 
> fact it seems to go out of its way to not be an 
> XML example). 

Correct :) GP-#1 does not concern the *input* format, only the XLIFF format (i.e. XML). It basically says: Regardless what the codes are ("<b>" or "[startBold]") they should preferably be outside the TEXT nodes in XLIFF.


> 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...

We have not looked at the last requirement (was #18, is now #17) during the meeting.


> So my conclusion (my opinion) is that guiding principle 
> 2.1 is not really related to 1.17.

Not at all related to the new #17 :)


> And its stated goal is contradictory to the stated 
> goal of 1.17. 

I don't think it does. And we certainly should start discussing it now, since #17 is our last item.

Are my tentative explanations helping?
I think the bottom line is that GP-#1 does not try to address the old Req-#18, which is now Re-#18.
But maybe I've missed something in your email.

-ys