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

[<bryan.s.schnabel@tektronix.com>]

Hi Yves,

> I think the bottom line is that GP-#1 does not try 
> to address the old Req-#18, which is now Re-#17.

Uh oh - I was comparing apples to oranges! 

The apology I issued for being a commenting lurker, rather than a meeting participant, at the onset of my last email; rings loudly and truly. I totally thought 2.1 was meant to be a guiding principle addressing the (current) requirement 1.17. 

I am sorry to have wasted bandwidth with my out-of-synch-argument. The good news is that I finally understand the very end of the meeting minutes that said:

"Yves: Only one item left!
Let's work on it by email and next meeting we may be able start discussing the implementation."

I will re-read my comments and see if any of them still apply, and see how many of them sound comical given my misunderstanding. Annotations within . . .

One interesting thing, my misunderstanding aside, is the observation that:

> it seems ironic to me that the example of what should be avoided in 1.17:
>
> This text is in <code native="[startBold]"/>bold<code native="[endBold]"/>.
>
> is (with the exception of the use of start tags instead of empty tags) exactly 
> what is stated in 2.1 as "what we want to try to achieve:
>
> This text is in <code native="[startBold]">bold<code native="[endBold]">.

-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com] 
Sent: Tuesday, September 14, 2010 12:45 PM
To: xliff-inline@lists.oasis-open.org
Subject: RE: [xliff-inline] Teleconference - Sep-14-2010 - 13:30 UTC - Summary

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.
[Bryan: I agree with Yves preserving well-formedness goes with the new 17, not the old 17]


>... 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.
[Bryan: I agree with Yves. The spirit is different because the rqt was different]


> 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.
[Bryan: I agree]

> 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.
[Bryan: yup]

> 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.
[Bryan: yup]

> 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 :)
[Bryan: thankfully]

> 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?
[Bryan: yes]

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.
[Bryan: nope - my email was totally misaligned and will stand up as one of the great works of comedy to come out of the XLIFF TC]

-ys



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php