Re: [xliff-inline] 1.16 Inline codes should have a way to store informationabout 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:             

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

To:

<>

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