OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: XLIFF TC Teleconference Summary - Nov-6-2012

Tuesday, 06 November 2012, 11:00am to 12:00pm EST
XLIFF TC Teleconference Summary
=== 1/ Roll call

Present: Bryan, DavidW, Yves, Shirley, Asanka, Helena, Christian, Ingo, Victor, Jungwoo, Kevin, Fredrik, Rodolfo, Joachim, Uwe, Tom, Michael, 
Regrets: DavidF

=== 2/ Approve Tuesday, 02 October 2012 meeting minutes:

Bryan move to accept the minutes
Rodolfo Seconds
No objections

F: URL in iCal is wrong.
(local file)

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

B: proposed to freeze features by next meeting.
.. Joachim seconded
.. this not include inline markup

R: proposal is fine.
.. still work to do. New feature freeze is fine.
.. so we can work on the accepted features

B: Idea is to either move items in section to section 3, or have the owners work on them to have them accepted before freeze.

R: C15: MIME type of XLIFF is being handled by OASIS.
.. we just have to vote to have a MIME type or not.
B: ok, we could do that, need to do that before next meeting.
.. any issue with the proposal?
F: fine. Maybe web ballot for the MIME type.
.. proposal for freeze is fine too.
R: let do a roll call ballot now.

Ballot: yes to freeze new features by the next meeting?
Passes: all yes.

B: also could someone recommend a free XML editor to work on the schema.
.. now let's talk about item #3

R: about PRs for modules vs PRs for exetnsions
R: long discussion.
.. difference in details.
.. should we make a distinction between module and extensions
.. DavidF wants to use MUST preserve for module
.. Yves noted that modules are optional, should be deletable.
.. question for the TC is should be preserve optional module or not?

B: So 'modules MUST be preserve' or 'SHOULD be preserve'?
R: hope others can weigh in.
F: if we put extension points where we cannot preserve it is not helping. So opinion is more MUST preserve for modules and extensions.
B: Agree with DavidF
K: agree with DavidF too. It's reasonable to have only Should for extension
J: but agreement between tool may not be relied on. Agree with Fredrik (MUST on both)
K: difficult to expect all extensions to be preserved. But I understand the scenario
R: maybe an electronic ballot to decide for each, so two option for each.
.. not sure the email discussion is clear enough.
.. not sure everyone has followed the discussion
B: many undecided?
DW: do we have extension inside segment?
R: no.
F: working on module for size will need to be in segment.
R: fine

Discussion of ITS in mrk:
Can a module be using a non-TC or not?
R: standard not finished yet
F: but when stable, that's ok
Y: will wait for when ITS 2.0 is stable, done.
R: not inside segment?

F: don't agree with *any* namespace.
.. need more qualification
R: what about the IPR?
Y: have not looked at it yet.
ACTION ITEM: Yves to post a proposal for 3rd party NS in module

Back to module/extension
H: can't decide now.
R: ballot will be: MUST or SHOULD for module, MUST or SHOULD for custom namespaces, and abstain
DW: agree with electronic ballot
V: from content publisher viewpoint I understand the difference, but we need the extensions to be preserved.
R: good choice, so you could vote.
.. personally would use should for both
V: in your case it make sense, but not in our scenario
R: understand that position
J: basically we don't want any extension to be removed.
F: agree with that too.
.. some use cases where people want to remove things
.. those cases means breaking the process
.. we cannot stop people to not follow the PRs, PRs can be used just to point to the guilty part.

B: We need to move on.
.. encourage discussion on the mailing list

=== 4/ Sub Committee Reports

--- 1. Inline text (Yves)

No meeting since F2F, working on filling examples.
Hope to decide if we can send a proposal to the TC at next meeting

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

B: F2F was 2 weeks ago, in Redmond.

for translation state: state + subState attributes and on the segment rather than the target

for the fs attribute: discussion's conclusion was that it should be a module
will be defined as an HTML preview. Bryan has action item to propose the text.

For the public portion several people joined us.
Breakout sessions

Will talk about symposium next time.
Many thanks to Microsoft for hosting the F2F.

=== 5/ Current XLIFF business

CL: information: talked internally about SAP and XLIFF TC.
Decision is that SAP will stop contributing to the TC for now.
We will join again when possible.

B: Many thanks for the many contributions.
.. Christian was the longest uninterrupted member of the TC.

B: any recommendation for a free tool to edit/view the schema?
R: eclipse has a module for the schema.
F: yes eclipse with XML tooling
.. didn't try with XLIFF
R: works fine
B: if you have other suggestions, please post it in the list.

F: need the mime type ballot too.
R: will try to make up something.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]