Face to Face Limerick added - Summary

[Yves Savourel <ysavourel@translate.com>]

Face to Face Limerick - Summary
Date:  Tuesday, 21 September 2010
Time:  01:00pm - 02:00pm ET


=== 1/ Roll call

Presents: Yves, Dimitra, Lucia, Bryan, Rodolfo, Andrzej, Doug, David, Peter, Christian, Asgeir.
Regrets: Andrew

6th face-to-face meeting
Thanks to Lucia and Dimitra for the organization.

Goal: get some work done.
Ok to go off agenda if needed.


=== 2/ Approve Tuesday, 7 September 2010 meeting minutes:
http://lists.oasis-open.org/archives/xliff/201009/msg00006.html

Yves moves to accept the minutes.
Rodolfo seconds
No dissents.



=== 3/ Current XLIFF business
1. Move our spec into Docbook
http://lists.oasis-open.org/archives/xliff/201007/msg00009.html
a. Filter current spec into Docbook (Bryan)

Not done yet.



=== b. XLIFF as an ISO standard (Peter)
http://lists.oasis-open.org/archives/xliff/201008/msg00029.html

Peter not there yet.



=== 4/ XLIFF Inline text SC report

Yves: Alsmots done with requirements. One more left, then on to implementation.
Rodolfo: Arle being able to provide tMX-related feedback?
Yves: Yes

Christian: 1 requirement outstanding? which one?
Yves: yes, the last one.

Dimitra: So next meeting is about implementation?
Yves: no quite: first closing the last requirement; possibly look at symposium feedback too;
then implementation, so maybe start at the next meeting, otherwise the one after.


=== Backward compatibility:

Bryan: what should be discuss now? 
David: charter maybe? Item #5.
Do we have an obligation for backward compatibility?

Rodolfo: 2.0: ok to break compatibility. Major change.
Yves: agree.
Peter: had the discussion before. Same conclusion as Rodolfo.

Bryan: anyone think 2.0 should be backward compatible?
No one does. -> 2.0 can be not backward compatible.
David: we should vote.

Proposed motion: "The TC proclaims that XLIFF 2.0 needs to give precedence to satisfying requirements over backward compatibility with 1.2, if necessary."
Yes: means we agree, No: do not agree.
Vote is conducted.
Results: Yes unanimously.



=== Conformance Discussion

Most of the remaining part of the meeting was a long discussion about conformance, compliance, validation and related topics. There was no consensus on what to do on that subject (besides continuing working on it) at the end.

There seem to be two main positions:

- one that wants the conformance to be defined for the XLIFF documents, and leave anything to do with application, process, or other aspect out of conformance.

- one that would like to integrate some way to define how applications should process the document in a way that is acceptable.

The following is a *partial* summary of the discussion.
It is probably not accurate in some parts and has many holes as the voice communications was difficult at times.


---------- start of partial and not always accurate summary ----------

Rodolfo: we started a thread on conformance, but it bogged down when talking about compliance.
Bryan: this may benefit from panel at the symposium

David: difference?
Rodolfo: they are difference: the XLIFF doc may be conformant, but the tool doesn't work correctly with it.

Processing req: Importance is to return a valid (conformant) XLIFF output if you get a conformant input.

Not sure we can assess the conformance of the process.

Example: tool a generate valid XLIFF 1.2
A tool B re-order attributes -> still valid
But tool A has problem with the output despite its validity.
Tool B was conformant.

App and doc conformance are different things.

Tools A -> xliff -> tool B add <phase> -> if tool A does not recognize it, is the process wrong?

Modular approach allows to fine-tune the conformance.
Can be solve piecemeal.

Asgeir: 1.2 has many features not well-defined.
We should say what the tool should/must do with some features.

Bryan: maybe we can require to have our 2.0 spec to have each para with a description of the conformance.

Rodolfo: would be complicated.
Also expectations are different. Defining all expectation may be difficult for each element and attribute.

Christian: modularization may help for this.

Rodolfo: TMX example of different level proved to be an issue.
2.0: we should at least have compliance with core.

David: Compliance is binary: it is or it's not.
Spec must say what it means to be complient.

Bryan: for 1.2 we tried hard to not have to do with the compliance so we could finish it.

David: with 2.0 we have experience, things possible now were not before.

Bryan: agree with David about look at things piecemeal.

Christian: would like a ballot for 2.0 complience

"The work has to be done with respect to processing expectations. Each data category and its possible values has to be tied to two things: a) the provenance and b) the processing expectations."

Example: restype in 2.0, definition of possible values 'p'. Processing expectation could be: an application that do rendering should render a paragraph.

Christian: we may need to remove the part about provenence for this ballot
David: it's very specific.

"The work has to be done with respect to processing expectations, for each data category and its possible values."

Dimitra: the word expectation may be interpreted differently.
Rodolfo: very hard to define all category and values, not a reasonable expectation

Christian: important to be able to implement only parts of the standard and still be compliant.

Rodolfo: get the feeling we are not clear on what is going to be compliant: app or doc, or both.
If just document: no need for expecation. If also application: we have a problem.
Cannot be abstract or high-level.

Christian: two types of conformance at high level, then a technical level.

Rodolfo: we have to set the rules. we can do that for documents.
not possible for applications.

David: would propose a paragraph: ...

Rodolfo: proposal for a conformance clause:
-----
An XLIFF document is said to be conformant with this specification if:

1) It is a well formed document according to the specifications of
Extensible Markup Language (XML) 1.0, defined at http://www.w3.org/TR/xml/

2) It is a valid document according to the grammar rules defined in the XML
schemas that are part of this specification.
-------

Christian: that's the intention of my proposal: for each data cat and its values we have a conformance section helping the implementer to know what to do.

Rodolfo: cannot be called a "conformance section" (OASIS has rule where those are placed)

Christian: that's ok.

D: conformances are binary and modules are optional. processing requirement would be in the document.

Rodolfo: a doc doesn't have Processing Req.

Bryan: evidence of the pro-req is in the doc.

Rodolfo: TMX example: several level of compliance, tools for certifying. Impossible to test all aspects: the candidate can pass the set of tests, but were still not ok for real process.
same for XLIFF. All we can evaluate is the document.

...

Rodolfo: as a TC we don't have the authority to declare tools conformant or not.

...

Rodolfo: no solution about the conformance issue.
Ballot proposed:
"XLIFF 2.0 should define conformance for document only and nothing else."

David: this does not exclude validation of processing.

Vote: yes means we agree, vote no = disagree.
yes=2, abs=3 no=4.

---------- End of partial and not always accurate summary ----------



Bryan: any other business?
None.

Best wish for the presenters at the symposium.

-meeting adjourned-