OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-seg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xliff-seg] Pro/Cons on xml:tm methods


Hi Yves,

Thank you for your comments and pointing out the practical issues involved 
concerning paired tags and sub-flows. <tm:tu> elements cannot split xml 
elements. In the instance where an end of a sentence is contained within a mixed 
content element the overriding rule is that of XML integrity. Sub-flows can be 
handled in one of two ways:

1) The sub-flow remains within its parent <tm:tu>.
2) The sub-flow can be separated out into a new trans-unit with a marker 
inserted to allow for the correct placement on merging.

Sub-flows are not normally a problem as they have been handled in the initial 
extraction into XLIFF.

Best Regards,

AZ


Yves Savourel wrote:
> Hi all,
> 
> My action item for tomorrow's meeting was to look at the pros and cons of
> using the method Andrzej proposed a while ago.
> 
> The original proposal can be found here:
> http://lists.oasis-open.org/archives/xliff-seg/200403/msg00015.html
> 
> The xml:tm specification can be found here:
> http://www.xml-intl.com/docs/specification/xml-tm.html
> 
> An article on xml:tm can be found here:
> http://www.xml.com/pub/a/2004/01/07/xmltm.html
> 
> 
> Pros:
> 
> Introducing additional element is cleaner that re-purposing some of the
> existing XLIFF element since we don't have to change the meaning of existing
> XLIFF elements.
> 
> Using a separate namespace is good because it allows the namespace to evolve
> separately from XLIFF and can be changed without changing XLIFF. Although
> this could be seen as an issue in some cases (which version of xml:tm is
> supported with which version of XLIFF, etc.)
> 
> The mechanism can be directly mapped in other XML formats if necessary,
> allowing to preserve seamlessly the segments outside of XLIFF.
> 
> 
> Cons:
> 
> - Introducing extension inside <source> and <target> should be looked at
> very carefully. If it is to be adopted it should be done along with strict
> guidelines on how tools should deal with the extensions, how they should
> treat their content, etc.
> 
> - Using xml:tm does not (as far as can see) solve the issue of how to deal
> with paired tags that become isolated once the segmentation. While in using
> xml:tm in a normal document this is probably resolved by closing and opening
> inline element when needed, that solution may not be viable for XLIFF where
> we need to merge. As Magnus pointed out, this problem is going to be an
> issue is just about any segmentation representation.
> 
> Another problem is how to treat sub-flow. For example how a XLIFF <sub>
> element would be treated. I don't think that the current xml:tm
> specification allows for a <tm:tu> to embed another <tm:tu>. This could
> probably worked out.
> 
> 
> That's all the notes I have for now.
> 
> Cheers,
> -yves
> 

-- 


email - azydron@xml-intl.com
smail - Mr. A.Zydron
         24 Maybrook Gardens,
         High Wycombe,
         Bucks HP13 6PJ
Mobile +(44) 7966 477181
FAX    +(44) 870 831 8868
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.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]