XLIFF TC Telelconference - Summary

[Yves Savourel <ysavourel@translate.com>]

XLIFF TC Teleconference - Summary
Date:  Tuesday, 02 November 2010
Time:  11:00am - 12:00pm ET

=== 1/ Roll call

Presents: Arle, Bryan, Asgeir, Yves, Rodolfo, Christian, Andrew, David, Lucia
Regrets: Dimitra
Absents: Peter


=== 2/ Approve Tuesday, 19 October 2010 meeting minutes:
(http://lists.oasis-open.org/archives/xliff/201010/msg00009.html)

Bryan moves to accept the minutes
Rodolfo seconds
No dissent

Rodolfo: modify the charter requires a ballot and we can't keep modifying it.



=== 3.1. Expression if gratitude to Doug for his many contributions, and best wishes on his future activities

Note for member count: Doug has left his company, so not a voting member now.
Bryan: TC is very grateful for Doug's contribution
Did a lot of work (transitional/strict, representation guide, etc.)



=== 3.2. Dee Schur announced the OASIS OAXAL Webinar, 16, November
(http://lists.oasis-open.org/archives/xliff/201010/msg00020.html)

XLIFF figures prominently in OAXAL.



=== 3.3. David proposes a ballot on *conformance criteria and processing requirements in xliff 2.0*
(http://lists.oasis-open.org/archives/xliff/201010/msg00002.html).
a. This is the wording as David indicated in the 19 October meeting
----- ballot wording:
TC sets as the following methodological principles for XLIFF 2.0 re conformance and processing:
1. Each element and data type must be accompanied by clearly specified conformance criteria
2. Conformance criteria must be binary, i.e. satisfied or failed, no shades of grey or levels of support.
3. Conformance criteria must include well-formedness and processing requirements
4. Processing requirements must be defined in terms of well-formedness and specific allowed values of elements and data types before and after processing.
----- 
b. Christian initiated the "Input to discussion on Conformance" 
(http://lists.oasis-open.org/archives/xliff/201010/msg00013.html)


Rodolfo: info for conformance for each element and attribute, so most of this is fine.
But can't define processing requirements for conformance
Conformance of document, not conformance of application.

Arle: Example file v.s. browser. 
Rodolfo: MSIE and FF for example, different rendering with same valid HTML

Bryan: example with ITS?
Yves: ITS is a processing standard, so maybe a bit different.

R: DITA is another example: same file, different outputs.
We can set processing expectations for attributes, etc. but we cannot have this as a conformance.

Arle: difference between file conformance and semantics
Bryan: For example removing group cannot be conformance then?
Rodolfo: it's important but it cannot be validated
Another example: modifying the source with <mrk>, the original tool may not like it, but it's valid.

We're talking about not having processing expectation in conformance clauses

Bryan: maybe not for every situations, but critical things.
Rodolfo: few things we can have: like don't remove extensions, but it may not be enough

David: extensions should have no more processing expectations tha 'don't remove then'. But group deletion also should be a processing expectation.
Rodolfo: we could say 'don't change structure markup'

David: maybe different (more feasible) with modules in 2.0.

Arle: decisions then have to be done now, without knowing what other may need to do later.

David: we could use current tool's extension to see what is used/needed.

Yves: Hard to validate processing expectations
Arle: conformance to processing expectation very hard to test, TMX as example.

Asgeir: we have states in XLIFF, it's different.
Example of 'must-understand' in SOAP.

We have to have some form of processing expectations, flexible but still implementable.

Other standard (e.g. CSS) manage to validate CSS rules -> browser tests.
Maybe we could have the same: before / after validation

David: yes, it's important. XLIFF is a localization processed standard.
Rodolfo: XLIFF is an exchange format
David: states-based format (extraction, translation, edit, etc.)
There should be some kind of 'state/phase' module

For example, issues with 1.2 are coming from different ways to represent segmentation.
Rodolfo: then we introduce other issues, segmentation on extraction time should be fine as well
David: yes, but segmentation vs. extraction should be distinct

Rodolfo: important to distinguish between conformance and processing expectations
Arle: agree, we do need processing expectations, but maybe not in main conformance

David: my take of user feedback is that the standard does not ensure interoperability because the lack of well-defined processing expectations
Rodolfo: not just that (extensibility, language code, etc.)

Yves: Seem we all agree (processing expectations is useful/needed) but we disagree where to document them (in conformance or outside)

David: I think processing expectations belongs to conformance clause
But the idea is to describe them per module.

Rodolfo: my early draft was considered not enough.
See http://lists.oasis-open.org/archives/xliff/201006/msg00001.html

David: it's certainly connected, but some differences
Rodolfo's proposal covers part of what I'd like to see.

Rodolfo did propose ballot to have processing expectations in conformance
David: think proposed ballot is 'stronger' (i.e. more than just document only)
Both connected but different. Rodolfo's is specific on parts of the conformance. Mine states principle for conformance clauses

Rodolfo: we need to follow the OASIS template:  the conformance section of the specification.
Rest of the specification is open to more. E.g. processing expectations at element or attribute level.
David: The tough part is defining processing expectations for each requirement.
The conformance section just points to other parts in the specification

Christian: We need to progress. Users want XLIFF to move forward.
Rodolfo: +1, but we need to define conformance section and charter

Bryan: conformance section and charter are important
We have reached a point where all have been heard.
Will try to look were differences lie and resolve them, through a ballot clear enough.
Last straw poll show few ready to vote.
David: should spend no more than 10mn next time

ACTION ITEM: all be ready to craft a ballot representing the different opinions.



=== 10/ New Business

None.


- Meeting Adjourned