Re: [xliff-inline] 1.16 Inline codes should have a way to store informationabout the effect on the segmentation

[David Walters <waltersd@us.ibm.com>]

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:

1. A way of defining an inline XLIFF element as causing a break in the segmentation.
2. A way of defining that a period is not a sentence delimiter (i.e. product -unique abbreviations).
3. 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