Description:
https://wiki.oasis-open.org/xliff/F2F2015?highlight=%28f2f%29%7C%28berlin%29
==========
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
==========
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:
- have both author as is plus ITS attributes. Pro:
- crazy idea to put all ITS information into author field.
- Key
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.
- author and ITS can co-exist. Flag itsm: says “yes” or “no”. Tools that don’t know ITS prov just ignore it.
- Final solution agreed was 4)+2) without the flag. On extraction from source the XLIFF author attribute is overloaded with all the its Provenance info except references to external provenance, also all itsm attributes available are populated. Tools that don’t understand itsm just manipulate the xliff 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]
==========
Attendance:
| Meeting Statistics |
| Quorum rule |
51% of voting members
|
| Achieved quorum |
no |
| Individual Attendance |
Contributing Members: 7 of 30 (23%)
Voting Members: 5 of 12 (41%) (used for quorum calculation)
|
| Company Attendance |
Contributing Companies: 4 of 13 (30%)
Voting Companies: 4 of 7 (57%)
|