OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-inline message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xliff-inline] Teleconference - Aug-10-2010 - 13:30 UTC - Minutes


We can certainly make sure to use a more XML-like notation for the example.

 

From: bryan.s.schnabel@tektronix.com [mailto:bryan.s.schnabel@tektronix.com]
Sent: Wednesday, August 11, 2010 3:08 PM
To: arle@lisa.org; Yves Savourel; xliff-inline@lists.oasis-open.org
Subject: RE: [xliff-inline] Teleconference - Aug-10-2010 - 13:30 UTC - Minutes

 

Hi all,

 

I like the new wording for a).

 

And I know the example was not meant to be included in the actual requirements. But if we were going to include an example, I would make a case to make it also comply with requirement 18 (which I recently proposed), that says for well-formed XML input that does not span segments (like this sample, "I like <i>italics</i>."), it is best practice to preserve the inline XML element as an XML node.

 

So I would rather see an example of the XLIFF that preserves the node.

 

Not like this:

XLIFF: I like <XLIFFtagOfSomeSort/>italics<XLIFFtagOfSomeSort/>.

 

But rather like this:

XLIFF: I like <XLIFFtagOfSomeSort>italics</XLIFFtagOfSomeSort>.

 

Now if the source was, say, RTF:

{\insrsid12611904 \hich\af35\dbch\af11\loch\f35 I like }

{\i\insrsid12611904\charrsid12611904 \hich\af35\dbch\af11\loch\f35 italics}

{\insrsid11469172 \par }

 

I'd be less picky about preserving the inline as an XML node.

 

I know my hair-splitting is off-topic for requirement 12. Forgive me for trying to set the stage for requirement 18.

 

Thanks,

 

Bryan

 

 

From: Arle Lommel [mailto:arle.lommel.lisa@gmail.com] On Behalf Of Arle Lommel
Sent: Wednesday, August 11, 2010 8:04 AM
To: Yves Savourel; xliff-inline@lists.oasis-open.org
Subject: Re: [xliff-inline] Teleconference - Aug-10-2010 - 13:30 UTC - Minutes

 

Yves, on further consideration, how about we rephrase point A as:

a) to store only the XLIFF representation, discarding the native data

I think this is clearer, because it's not really that we're just discarding everything, as in the following:

Source: I like <i>italics</i>.
XLIFF: I like italics.

But rather going for something like this:

XLIFF: I like <XLIFFtagOfSomeSort/>italics<XLIFFtagOfSomeSort/>.

The existing text could imply the former as well as the latter possibility.

-Arle

On 8/10/10 10:51 AM, sic scripsit Yves Savourel:

Requirement #12: (was #10, #11, and #12)
 
After discussion, the three requirements related to the representation of the native data were grouped into a single one (#12), with the following wording:
 
[
There must be three ways to deal with the native data corresponding to an XLIFF inline code:
 
a) not to store it at all
 
b) to store it along with its XLIFF representation
 
c) to store a pointer to it along with its XLIFF representation
]
 
  

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]