XLIFF Inline Markup SC

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

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  

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  

Hi david, all, > ...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. I'm not sure #2 is relevant directly to XLIFF. My guess is that things like that may be better stored in whatever segmentation rules the system is using. For #1: sounds good. Something like break='yes' or whatever. For #3: I suppose that could be use for content where things like tabs are seen as inline codes, etc. We may also want something to indicate that a code should simply be ignored. This relates to the equiv attribute we have. Are we being redundant here? As a general note, I'm a bit worried about implementation for segmentation using XLIFF itself. XLIFF is by definition just a transport format. I'm not sure how those information can be easily taken into account when actually executing the segmentation, except if the tools internal format on which the segmentation rules are applied is also some kind of markup itself. But that's a different issue. -ys