Re: AW: [xliff] XLIFF inline elements with spacial characteristics

[Andrzej Zydron <azydron@xml-intl.com>]

Hi Florian,

Many thanks for your email. The mechanism you suggest would be ideal as 
it is proscriptive and therefore easy to interpret. It would be ideal 
for GMX-V, where inline elements are treated as being totally 
transparent for word and character count purposes. It would be really 
good to get this into XLIFF 1.2. I would certainly like to see it 
incorporated as we could then refer to this mechanism directly from GMX-V.

Best Regards,

AZ

Florian Sachse wrote:
> Hi Andrzej,
> 
> we are currently working on the question how tagging can help to simplfy the
> handling of text processing in our localization tool and we want to solve
> similar problems like,
> 
> Access keys: F&ile where the '&' breaks the word file and a lot of functions
> like spellchecker or terminology look up have to handle this issue.
> 
> Or we have file formats like delphi where null character are used as
> separators:
> File0This is the tooltip help for file.
> 
> For our internal representation we want to use something like the x-element
> extended by an additional attribute (currently) called rawreplace.
> 
> The two examples now would look like this:
> 
> F<x id='1' ctype='x-akey' rawreplace=''>ile and
> File<x id='1' ctype='x-ch-null' rawreplace=' '>This is the tooltip help for
> file.
> 
> By just evaluating rawreplace a tool can create a string "File" or "File
> This is the tooltip help for file." and can use this string for further
> processing like wordcount etc. This trick also allows a correct
> transformation back to the original format even if the tagged string has
> been edited. and without knowing the original text. Taking your example, the
> question is what should happen if <br> has a preceding space. Should a space
> still be added to the XLIFF representation or not?
> 
> I hesitate to really open a discussion about a solution within the XLIFF
> spec right now, as we want to finalize XLIFF 1.2 But may be you could use an
> extension like x-rawreplace for this purpose.
> 
> Best regards from Bonn,
> Florian
> 
> -----Ursprüngliche Nachricht-----
> Von: Andrzej Zydron [mailto:azydron@xml-intl.com]
> Gesendet: Montag, 6. März 2006 11:56
> An: xliff@lists.oasis-open.org
> Betreff: [xliff] XLIFF inline elements with spacial characteristics
> 
> 
> Hi Everyone,
> 
> GMX-V (Global Information Management Metrics eXchange - Volume) is a
> draft LISA OSCAR standard for word and character counts
> (http://www.lisa.org/standards/gmx/). This should bring some sanity to
> word and character counts. GMX-V is predicated on a canonical form that
> is based on XLIFF.
> 
> We are almost at the end of the internal GMX-V review before it goes out
> for final public comment. We have had a final discussion concerning
> inline elements that imply some form of white space, but may not be
> necessarily preceded of followed by any spaces e.g.
> 
> <p>This is a<br/>that is not preceded nor followed by spaces.</p>
> 
> This instance would be rendered in XLIFF as:
> 
> <source>This is a<x ctype="x-html-br"/>that is not preceded nor followed
> by spaces.</source>
> 
> In the proposed GMX-V standard it is recommended that the program that
> is creating the XLIFF file precedes the any inline elements with spacial
> characteristics with a space if there is not one present:
> 
> <source>This is a <x ctype="x-html-br"/>that is not preceded nor
> followed by spaces.</source>
> 
> This is specific to XLIFF files created for GMX-V purposes.
> 
> I was wondering if it would be desirable/beneficial to consider this
> requirement within the XLIFF specification itself. Certainly having a
> space would assist any segmentation algorithms etc. The onus would be on
> the merge program to remove any such spaces that were inserted. It is
> only the extraction and merge processes that can do this as they have
> the required intimate knowledge of the source environment.
> 
> Please find attached the latest version of the GMX-V draft specification
> (version 0.7).
> 
> Best Regards,
> 
> AZ
> 
> 
> --
> 
> 
> email - azydron@xml-intl.com
> smail - c/o Mr. A.Zydron
> 	PO Box 2167
>          Gerrards Cross
>          Bucks SL9 8XF
> 	United Kingdom
> Mobile +(44) 7966 477 181
> FAX    +(44) 1753 480 465
> www - http://www.xml-intl.com
> 
> This message contains confidential information and is intended only
> for the individual named.  If you are not the named addressee you
> may not disseminate, distribute or copy this e-mail.  Please
> notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
> E-mail transmission cannot be guaranteed to be secure or error-free
> as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses.  The sender therefore
> does not accept liability for any errors or omissions in the contents
> of this message which arise as a result of e-mail transmission.  If
> verification is required please request a hard-copy version. Unless
> explicitly stated otherwise this message is provided for informational
> purposes only and should not be construed as a solicitation or offer.
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------------------------------------
> Text inserted by Panda Platinum 2005 Internet Security:
> 
>  This message has NOT been classified as spam. If it is unsolicited mail (spam), click on the following link to reclassify it: http://127.0.0.1:6083/Panda?ID=pav_47379&SPAM=true
> ---------------------------------------------------------------------------------------------------
> 
> 


-- 


email - azydron@xml-intl.com
smail - c/o Mr. A.Zydron
	PO Box 2167
         Gerrards Cross
         Bucks SL9 8XF
	United Kingdom
Mobile +(44) 7966 477 181
FAX    +(44) 1753 480 465
www - http://www.xml-intl.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
may not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version. Unless
explicitly stated otherwise this message is provided for informational
purposes only and should not be construed as a solicitation or offer.