f2f Berlin 2015 (Face-to-Face meeting) | |
Name | f2f Berlin 2015 (Face-to-Face meeting) |
Time | Monday, 01 June 2015, 09:00am to 05:15pm WEST
(Monday, 01 June 2015, 08:00am to 04:15pm UTC) |
Description | https://wiki.oasis-open.org/xliff/F2F2015?highlight=%28f2f%29%7C%28berlin%29 |
Minutes | XLIFF f2f 01 June 2015 Present: Uwe, Bryan, Joachim, David, Ryan, Kevin, Felix Quorum not reached with 5 voters out of 12 ITS Module [overview of discussed categories and solutions is in the attached ITSProgress.xlsx] Directionality Felix proposing not to have directionality from ITS 2.0 in XLIFF 2.1 since XLIFF 2.1 already does the right thing like HTML5, having 3 value: ltr, rtl, auto, in alignment with UAX9. ITS 2.0 has legacy values ltr, rtl, lro, rlo, which are not recommended anymore. So there should be no mapping from ITS 2 to XLIFF 2.1 for directionality. Probably have a sentence in XLIFF 2.1 explaining the above, i.e. saying why we won’t have ITS directionality in XLIFF 2.1. Once ITS is updated with the proper values for directionality we may have a reference to ITS directionality in XLIFF 2.x again. Action: felix to supply text about directionality. Preserve Space TC discussion said, we don’t need to look at the wiki mapping anymore ITS Terminology Annotation Needs to assure that there is no ambiguity about the terminology information: external reference vs. reference to glossary. Felix: have a different link in the Example 3 – replace http://en.wikipedia.org/wiki/Terminology with a real term , e.g. “rock” http://iate.europa.eu/FindTermsByLilId.do?lilId=325975&langId=en Action: Felix to re-design the example. Already sent to David and Bryan Provenance Comparing change track module http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#changeTracking_module and ITS 2 provenance http://www.w3.org/TR/its20/#provenance Discussion on change track module use cases. Change track needs to allow inline elements. Content vs. metadata change tracking. Have provenance in ITS module, without relation to change tracking? Issues: 1) allow change tracking inline 2) interpret itsm value from the viewpoint of change tracking One suggestion: have all change track “author” as mapping target for the six pieces of information in ITS provenance, see table here http://www.w3.org/TR/its20/#provenance . Then have ITS provenance to declare the type. If somebody changes “author”, they would have to delete the itsm . Have a reference from ctr:author to URI that holds the provenance record. Then have itsm:prov=”yes” to trigger the interpretation of ctr:author as a URI: <ctr:revision ctr:author=”uri-prov-record” itsm:prov=”yes”> If itsm:prov is changed the referenced ITS prov record (which is at the extension point) also needs to be changed. Options: 1) take ctr as is and combine it with prov records like <ctr:revision ctr:author=”uri-prov-record” itsm:prov=”yes”> 2) like 1), plus allow ctr inline elements 3) re-design of ctr to allow usage of ITS provenance and more
Reference versus everything in author: ctr:author=”ryan-human-author:df-human-author”. This solution also needs itsm:prov=”yes”, so reference solution is cleaner. Requirement for XLIFF process: no need to process the reference.
Options again:
Both 2) and 3) need itsm:prov=”yes” Flag itsm:prov=yes set - > you use ITS attributes in the change track, so you don’t use author.
In general itsm attrbutes (in scope of ctr) need to be killed when ctr is manipulated w/o itsm support. When itsm info is lost on the roundtrip, its aware mergers need to repopulate Prov from the single author attribute.
If there is provRecords ref on the ITS side: generate several <item> elements, one for each provenance records.
itsm: attributes for provenance can appear also on mrk. Need a scenario for killing the provenance information. If authorship on upper level is changed it should be deleted on lower level.
“Reference to external provenance information”: not mapped into XLIFF, would need to be mapped via an extension. XLIFF 2.1 timeline Shooting for October, but not sure if that is doable. AI Bryan and Kevin: to backplan from OS by end of October for csd01/csprd01 XLIFF 2.2 moving forward We will have requirements gathering for 2.2 on Wed June 3. XML serialization and fitting features will continue in XLIFF TC as XLIFF 2.2, but the community wants to go beyond XML and we don’t have mandate to do that in XLIFF TC, as currently chartered Joachim suggested using fs like HTML for managing layout roundtrip dF: Create resourceItem with context=“no“ mime type HTML, fs is not for roundtrip just for preview dF: Please suggest this on June 3, this is just to see and summarize what may come up on 3rd. Christian will represent ULI requirements, Chase will report on remaining gaps in XLIFF:doc coverage.
Object model and other serializations Discussion on how to move non-XML work items forward. Idea is to move forward in XLIFF TC and see where to publish (Oasis, ETSI, …) What is the goal: standardize syntax (json-serialization), API, or object model. Easier to think about something as a json-serialization, not a full-scale object model. Should not talk about object model but json serialization, potentially also API. Panel – “serialization panel”? ITS again – MT Confidence MT Confidence. On XLIFF Side: matchQuality. What to do with its:annotatorsRef? Mapping with ITS: must be a URI. Need to take out mt confidence related info from annotatorsRef. Example from ITS XLIFF Mapping wiki: https://www.w3.org/International/its/wiki/XLIFF_2.0_Mapping#MT_Confidence_.5BTRANSER_TO_XLIFF_2.1_DRAFT_IN_PROGRESS.5D Handling of conflict with “origin” like with MT confidence.
Rule file Action: Felix to double check namespace usage https://www.w3.org/International/its/wiki/XLIFF_2.0_Mapping#Rules_file_for_the_mapping
Conformance Seperate sub conformances. ACTION: Felix to create a sentence for the spec. Allowed characters Do like in the wiki but also structural elements not including XLIFF elements (up to “file”).
[Meeting adjourned] |
Agenda | XLIFF 2.1 1) ITS Module 1. Overview of gaps (dF) 2. not problematic data cats (Term, TA, lang, etc.) 3. space handling (Yves) 4. slr profile (Fredrik) 5. MT Confidence (dF) 6. Provenance + ctr (Ryan) 2) Advanced validation 1. current schematrons and NVDL (Felix, Soroush) 2. schematrons and NVDL to cover the ITS module (Felix, Soroush) 3) Admin 1. pinpoint the current schedule for 2.1 release (Bryan, Kevin) 2. Report on progress of the ISO submission of XLIFF 2.0 (dF) XLIFF 2.2 Short preparation for the requirements gathering panel on Wednesday June 4 (dF) Non normative work 1. Committee Note: XLIFF 1.2 vs. XLIFF 2 (Yves) 2. Committee Note: XLIFF 2 TBX mapping (Fredrik, dF) High level issues Discuss where to work on: 1. JSON serialization 2. OM - XML independent Re-charter XLIFF TC? Pros and Cons (dF) The objective of this is to have if possible a TC position on that prior to the OM panel on Wed June 3 |
Submitter | Dr. David Filip |
Group | OASIS XML Localisation Interchange File Format (XLIFF) TC |
Access | This event is visible to OASIS XML Localisation Interchange File Format (XLIFF) TC and shared with
|
Referenced Items | |||
Name | Type | Date | Action |