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


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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

Subject: RE: [xliff] XLIFF 2.0 Core

Hi Yves,

SDLXLIFF files are plagued of custom elements around segments. I added multiple <ignorable> before and after a segment to support that. 

We could have matches at <unit> and at <segment> level but I'm not sure it is necessary. If you have a match at <unit> level generated from a paragraph, it can be segmented with the same mechanism you use to split the extracted text into <segments>.

It's OK for me to move <match> and <note> to a different namespace, as long as it is an official namespace defined by the XLIFF TC. 

I can extend the XML Schema to include <xliff> and <file> elements. If there is agreement, I would create a separate schema for <match> and <note> and another one for a generic <inline> element (it would be a placeholder until the subcommittee finishes the definition of inline markup).

I think that the core should not have <header> or equivalent. Do we agree?

Rodolfo M. Raya   <rmraya@maxprograms.com>
Maxprograms      http://www.maxprograms.com

> -----Original Message-----
> From: Yves Savourel [mailto:ysavourel@translate.com]
> Sent: Thursday, April 07, 2011 10:25 AM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] XLIFF 2.0 Core
> Hi Rodolfo, all,
> Thanks for the XSD, it's very handy.
> I like the more specific <match> instead of the all-purpose <alt-trans>.
> It makes sense to specialize the elements.
> But I don't think candidate matches should be part of the core. (Same for
> <note>).
> To me the core would be just the data needed to extract, translate and
> merge, with possibly a few meta-data like resname, restype, etc. that could
> be considered as basic properties.
> Another though about <match>: We probably need to handle also the cases
> where there are match candidates offer for both the whole unit and for each
> segment, instead of just for each segment. Tools like WorldServer offer such
> feature for example.
> Handling the "outside" extra spaces/codes with <ignorable> looks good.
> Do we have a case for allowing multiple <ignorable> at each ends? I cannot
> think of any tool that would have more than one inter-segment span. Not a
> big issue: allowing 0 or more just makes it a bit less simple to handle.
> -ys
> ---------------------------------------------------------------------
> 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

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