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: Pro/Cons on xml:tm methods


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



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