OASIS XML Localisation Interchange File Format (XLIFF) TC

Hi all,   My recollection of the Berlin’s conclusion on that topic is that:   1.   Metadata is allowed only in the Translation candidate module. 2.   Using it in the extension points of the other modules is not valid. 3.   But we would like remedy this situation, and we would do this by creating new versions of the modules where Metadata would be allowed. (This affects only the modules, not the core) 4.   We would also add language in the specification that clarifies the fact that modules are valid only where the specification declare them.   Cheers, -yves   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King Sent: Tuesday, June 16, 2015 6:03 PM To: Schnabel, Bryan S (bryan.s.schnabel@tektronix.com) Cc: 'xliff@lists.oasis-open.org' Subject: [xliff] Meeting agenda for next XLIFF call   Hi Bryan, you may have missed my comment in the chat on the XLIFF TC call, but I would like us to discuss whether <mda:metadata> can be allowed at all extension points in the next call and try to come to a consensus and look at having the proper clarifying language placed in the spec.   Thanks, Ryan

Hi Yves,   Thanks for the summary, that is also my recollection. And to be sure, this means that for 2.0, #1 and #2 are the point of record. #3 and #4 would then be 2.1 features, correct?   Additionally, do we want to remedy <res:resourceData> not being allowed on <group> as a module? Or will that forever be off-limits because it necessitates a change to core?   Thanks, Ryan   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel Sent: Tuesday, June 16, 2015 2:02 PM To: XLIFF Main List Subject: [xliff] The Metadata module   Hi all,   My recollection of the Berlin’s conclusion on that topic is that:   1.   Metadata is allowed only in the Translation candidate module. 2.   Using it in the extension points of the other modules is not valid. 3.   But we would like remedy this situation, and we would do this by creating new versions of the modules where Metadata would be allowed. (This affects only the modules, not the core) 4.   We would also add language in the specification that clarifies the fact that modules are valid only where the specification declare them.   Cheers, -yves   From: xliff@lists.oasis-open.org [ mailto:xliff@lists.oasis-open.org ] On Behalf Of Ryan King Sent: Tuesday, June 16, 2015 6:03 PM To: Schnabel, Bryan S ( bryan.s.schnabel@tektronix.com ) Cc: 'xliff@lists.oasis-open.org' Subject: [xliff] Meeting agenda for next XLIFF call   Hi Bryan, you may have missed my comment in the chat on the XLIFF TC call, but I would like us to discuss whether <mda:metadata> can be allowed at all extension points in the next call and try to come to a consensus and look at having the proper clarifying language placed in the spec.   Thanks, Ryan

> And to be sure, this means that for 2.0, #1 and #2 are the > point of record. > #3 and #4 would then be 2.1 features, correct? Yes, #3 and #4 would be for 2.1. > Additionally, do we want to remedy <res:resourceData> not being > allowed on <group> as a module? Or will that forever be off-limits > because it necessitates a change to core? My understanding is that, yes, it would be a core change, and therefore a 3.x change. -ys

Thanks, Yves. We will look at alternate ways then to associate our "extended terminology" with <gls:glossary> in the meantime. From: Yves Savourel Sent: ?6/?16/?2015 7:19 PM To: 'XLIFF Main List' Subject: RE: [xliff] The Metadata module > And to be sure, this means that for 2.0, #1 and #2 are the > point of record. > #3 and #4 would then be 2.1 features, correct? Yes, #3 and #4 would be for 2.1. > Additionally, do we want to remedy <res:resourceData> not being > allowed on <group> as a module? Or will that forever be off-limits > because it necessitates a change to core? My understanding is that, yes, it would be a core change, and therefore a 3.x change. -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