Hi Yves, all,
Would we need to align any discussion on segmentation with SRX? Or, phrased differently: Could we use SRX mechanisms for describing segmentation features?
Cheers,
Christian
From: David Walters [mailto:waltersd@us.ibm.com]
Sent: Freitag, 2. September 2011 00:00
To: Yves Savourel
Cc: xliff-inline@lists.oasis-open.org
Subject: Re: [xliff-inline] 1.16 Inline codes should have a way to store information about the effect on the segmentation
One of the problems with using pre-defined values for a type attribute is that a list cannot cover all possible situations. For example, in 1.2, the "ctype" attribute could have values of "image", "pb" and "lb" for <x/> and <ph>, What about values for replacement variables, tab, some XML unique formatting control, etc. Having the user create their own "x-__" value seems to defeat the purpose because tools will not know how to handle those values with respect to segmentation.
I would think that segmentation-related information in inline elements should be defined with a separate attribute and not combined with an existing attribute. For example:
- A way of defining an inline XLIFF element as causing a break in the segmentation.
- A way of defining that a period is not a sentence delimiter (i.e. product -unique abbreviations).
- A way of defining that an inline XLIFF element should be handled as whitespace.
David
Corporate Globalization Tool Development
EMail: waltersd@us.ibm.com
Phone: (507) 253-7278, T/L:553-7278, Fax: (507) 253-1721
CHKPII: http://w3-03.ibm.com/globalization/page/2011
TM file formats: http://w3-03.ibm.com/globalization/page/2083
TM markups: http://w3-03.ibm.com/globalization/page/2071
Yves Savourel ---09/01/2011 03:49:04 PM---Hi all, 1.16 is the last requirement we have not started to discuss.

From: |  Yves Savourel <ysavourel@enlaso.com>
|

To: |  <xliff-inline@lists.oasis-open.org>
|

Date: |  09/01/2011 03:49 PM
|

Subject: |  [xliff-inline] 1.16 Inline codes should have a way to store information about the effect on the segmentation
|
Hi all,
1.16 is the last requirement we have not started to discuss.
"Inline codes should have a way to store information about the effect on the segmentation
As some inline codes may have an effect on the segmentation of a given content, it is useful if segmentation-specific hints could be stored along with an inline code.
For example: In HTML a <BR> element indicates a forced line break, while a <B>...</B> element should not affect the segmentation."
I can think of a simple way to fill that requirement:
In the list of pre-defined values for the type attribute of the given inline code we should include a few that corresponds to think like forced line-break. Basically the same as in 1.2 where type='lb' was indicating this.
Or we could have a new separate attribute that would just indicate the inline code possibly denotes the end of a segment: break='yes'. this would allow even custom type of inline codes to provide that information.
Any thoughts?
-yves
---------------------------------------------------------------------
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