RE: [xliff] Groups - Event "XLIFF TC Call" - Summary

[Yves Savourel <ysavourel@enlaso.com>]

Summary of XLIFF TC Call - July 3 2012


=== 1/ Roll call

Present: Yves, Bryan, Asanka, DavidW, Klemens, Helena, Jungwoo, Fredrik, Rodolfo, Victor, Tom, Peter, Ingo, DavidF, Joachim, Christian, Michael, Uwe, 


=== 2/ Approve Tuesday, 19 June 2012 meeting minutes:
https://lists.oasis-open.org/archives/xliff/201206/msg00041.html

Bryan moves to approve the minutes.
Tom seconds
No objections


=== 3/ XLIFF 2.0 (http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking )

Rodolfo: need a list of element for extensibility
Yves: will take this as an action item.

Fredrik: will move the bidi item to feature list.

Bryan: what type of validation for extensions.
Rodolfo: strict would be better but can't do this.
Lax means if the schema is there you validate
Skip means no validation
Possible issue with lax too.

Need PE for extension (ns and meta)
Yves will come up with an initial list too.

DavidF: different levels of options.
Modules not option if supported.
Maybe skip when not supported, lax otherwise.

Rodolfo: skip/lax is in schema can't be changed on usage.
Fredrik: PE also need to be define when you change the document (discard, etc.)

Rodolfo: metadata ready as a module
Need to define what we want to do.
Could be safely ignorable
Bryan: for metadata not the same since part of 'our' namespace

Rodolfo: extension should be ignorable
Removing is something different.
Bryan: agree
Yves: +1
Rodolfo: maintaining/updating is something also different (maybe should not be required)
DavidF: only if supported.

Should not use ext in a way it's mandatory for your round trip.
e.g. Apps should not rely on presence of ext for merging back

Helena: what is private use of extensions?
DavidF: by definition
Helena: so it's not private use (different from public).
DavidF: module would be 'public' user-ns would be 'private'
Bryan: ignore but don't delete may be safer way to go.
Worry about case like its:translate
DavidF: but we can't use that since we have own translate
Fredrik: need very clear rule in place where we modify structure (like on segment. E.g. what to do with the extension).
Rodolfo: using attributes in inline element is also an extension
Klemens: What about creating a Central repository for Extension Where Tools can Register their Extensions?
Rodolfo: we have schemes in wiki, but no documentation
Fredrik, DavidF: can't mandate using all extensions
DavidF: extension can move to a module stage at some point.
Fredrik: allowing removal lower the interest of the extension.
e.g. attribute in <xliff> could be preserved by all.
Rules may need to be defined per location.
Rules must be not link to the functionality of the extension
Christian: I would suggest that we craft a clause for "extensions" that is similar for example to http://www.w3.org/TR/REC-xml/#sec-white-space
Rodolfo: +1

Bryan: a lot of work will be needed on this.

Rodolfo: about Processing Expectations.
Should we not allow translate property to be changed?
Fredrik: +1
But we need a 'lock' feature too
At unit and inline level.

DavidF: think the process should decide if translate flag can be changed or not, not the spec.
Klemens +1
Fredrik: some cases are dangerous. E.g. when it *cannot* be translated (and merged back translated).
DavidF: changing translate at local level should be allowed
Joachim: any real case for translate=no to yes?
DavidF: open issue, for example segmentation change. So translate flag may be wrong.
Should be decided at process time
Fredrik: then going to yes should mean that that translation may not be merged.
Christian: not sure if we started to defined PE in a structure fashion.
Rodolfo: no one volunteered.
Fredrik: did this for editing target in inline content.
We should do this for all different areas that are stable.
Rodolfo: did add some PE as I was writing it.
But we need feedback.
DavidF: agree with Fredrik. Feature owner sould draft that.
We also need PR processing requirements
So they can be used in conformance statement.
Rodolfo: like MUST and SHOULD
DavidF: yes we can use them, but PE is not normative PR are normative

New soon member: Michael Ow (IBM)
Also: Klemens officially in TC now.



=== 4/ Sub Committee Reports

--- 1. Inline text (Yves)

Fredrik did gave a summary of the F2F meeting last time.
Out next call is next week.
Currently Yves is working on editing the spec to reflect the changes/fixes generated during the face-to-face.
We are reaching the end.
Hope to have something quite stable by the end of summer.


--- 2. XLIFF Promotion and Liaison SC Charter (David)

- Sent an email to TC to promote 3rd symposium
http://localizationworld.com/lwseattle2012/feisgiltt/
http://www.localizationworld.com/lwseattle2012/feisgiltt/xliffcall.html
http://linkd.in/L4t8vj
try to engage with bloggers
End of July is deadline for call.

So far: Interesting proposal from Microsoft.

Christian: we had summary for the 1st symposium.
Did it happened for 2nd?
DavidF: no
But we could summarize it before.
Christian: we should demonstrate we act on the community input.

Peter Reynolds (to All - Entire Audience):
David, Kevin Lossner is visiting me next week and I will get him to blog about it. Is there a tweet hash tag
Lets discuss Christian's at the sub committee
We also need better attendance at this event
The XLIFF TC was not as well represented as it could have been at the last one

--- 5/ Current XLIFF business
   
1. Announce Face to face https://lists.oasis-open.org/archives/xliff/201206/msg00010.html

Bryan: face-to-face TC meeting in Seattle.


2. Donna Parrish sent an email to the comments list pointing to the presentation Christian did in Paris. https://lists.oasis-open.org/archives/xliff-comment/201206/msg00004.html


=== 6/ New Business

Fredrik: group for 2.0?
Yves: +1
Rodolfo: There is a proposal.

-done