RE: [xliff] XLIFF 2.0 Core

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

Hi Rodolfo,

Yes. Good plan. Please keep the momentum going. I'll work on the technical ns issues behind the scenes.

- Bryan

-----Original Message-----
From: Rodolfo M. Raya [mailto:rmraya@maxprograms.com] 
Sent: Thursday, April 07, 2011 11:12 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] XLIFF 2.0 Core

Hi Bryan,

Would it be OK if I work with just one XML schema and then you break it into pieces (core + modules)?

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


> -----Original Message-----
> From: Schnabel, Bryan S [mailto:bryan.s.schnabel@tektronix.com]
> Sent: Thursday, April 07, 2011 3:04 PM
> To: Rodolfo M. Raya; xliff@lists.oasis-open.org
> Subject: RE: [xliff] XLIFF 2.0 Core
> 
> I hope nobody is worried about my uncharacteristic silence on this 
> thread (or maybe celebrating it ;-).
> 
> I'm following with much interest and I like the direction it is going. 
> I want to manage/look after an important side issue Rodolfo mentioned. 
> We will certainly need to think about the notion of a core-namespace 
> vs. module- namespaces, all falling under the *official* XLIFF namespace. I'll take this on.
> So let's keep the thread going, and I'll sign up for tracking the 
> administrative side-issues as they  arise.
> 
> - Bryan
> 
> -----Original Message-----
> From: Rodolfo M. Raya [mailto:rmraya@maxprograms.com]
> Sent: Thursday, April 07, 2011 7:07 AM
> To: xliff@lists.oasis-open.org
> 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?
> 
> Regards,
> Rodolfo
> --
> 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
> 
> 
> 
> ---------------------------------------------------------------------
> 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
> 



---------------------------------------------------------------------
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