[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: XLIFF-TC Meeting Minutes - 19 Mar 2013
=== I.A/ Roll Call
Present: Helena, Kevin, Shirley, Tom, Bryan, Uwe, DavidW, Asanka, Lucia, Joachim, Yves
Regrets: Victor
=== I.B/ Approve 05 Mar 2013 meeting minutes:
https://lists.oasis-open.org/archives/xliff/201303/msg00016.html
Tom seconds. No objections.
=== I.C/ Bryan to update the TC page with approved clarification - not done yet
=== 1.D/Ballot - "Should <mrk> be extensible?"
Tom: The vote tally for "Should <mrk> and <sm> inline elements be extensible by custom namespace *attributes*?" was Yes: 7 No: 0 Abstain: 1
Bryan: We did not cross the 50% threshold. Ballot proposal passed. The <mrk> will have extensibility.
=== II.A/ Review Approved Features in WIKI
C3) Native support for ITS.
DavidF: Two obstacles: i) extensibility of <mrk> ii) In the translation candidate module .. did not mange to propose the change approach to the suitability
..extensively discussed last time
..going to propose .. similarity and origin. idea is to go as explained by Yves in the wiki. .supported by Joachim
..Similarity, quality and suitability. There would be a confidence score..
..for ITS support .. ..ITS needs match quality for recording the MT confidence. I should be able to propose the other during this week.
Bryan: consensus?
DavidF: ..not sure whether this needs a ballot or not ..
..are you ok with changing it to the three attribute approach?
Yves: Yes.
DavidF: Perfect. I will edit the spec. This should be done by the end of this week.
(D15) Mime-type for XLIFF
Bryan: This is outside of the scope of the specification.
DavidF: I edited the wiki ..its external rather than the core module.. this will move forward when ready. I added info. to the wiki.
(R43) Change track module
Bryan: Don't have Ryan on the call.
Kevin: I believe it is done ..he may not have updated the wiki ..we could get him to do it today.
DavidF: It should be clear from the SVN state .. its not fully done, specification part is not written ..attributes and elements are added.. It should be trivial for Ryan to finish.
Joachim: I got an email from Ryan last Tuesday .. checked into the repository.. but didn't find them ..may be I looked at the wrong place..
DavidF: The elements and attributes are in the SVN, they are not quoted by the specification and do not appear in the master document and the editor's draft. It is kind of all-most done.
Helena: What was the reservation about the <couldn’t follow> values of the change track .. Validation piece? .. entry that potentially keep the normalized entry .. different file sequence. What do we do in those situation?. I am not aware of resolution of that discussion.
Bryan: The latest comment on validation proposal was today from Yves.
Helena: .. I don't see any discussion around normalization piece. Are we strictly starts with an ends with as Yves suggest? or are we allowing any kind of normalization? ..how that information get communicated across?
Joachim: Ryan sent a draft - that's the latest that I know. I could not see any topic on normalization there.
Helena: I read the latest copy of the update from Ryan. I still don’t see within the attributes.. how is normalization specified? do we even clear?
Kevin: It would be good to hear more feedback on this issue. We are happy to look into it.
DavidF: I definitely support the normalization.. there should be at least field, may be a compulsory field with a default value (e.g. canonicalization).
Helena: Default is always NFC or FCD. Otherwise ..either we say no normalisation at all .. or we say that there is always normalization built into it ..default is FCD or so.
DavidF: I support that approach.
Joachim: Do we really need to handle it? Shouldn’t it be in the domain of the tool which does the check to apply normalization to the string which is expressed in the validation?
Helena: It is all about interoperability - if you allow the tools do any interpretation, what is the point of doing validation?
DavidF: I agree. It should not be in the application logic. It should be in the standard.
Joachim: Wouldn't be then need to tell which normalization we want to have for the whole XLIFF document?
Helena: That's what I am asking.
Joachim: Ok. That's a valid point. But then it’s much more than the validation module.
Helena: Validation is on content in this case .. Currently it is very vague .. does not say how do you compare the values.. it should be very minimal or little bit comprehensive.
Bryan: I guess DavidF and Helena that they both favour on to be more comprehensive
Joachim: What would happen if you don't normalize on what is in the validation string and not on the content ..you'd get more errors like.. it is in the interest of the tool producers to apply normalisation ..A cheap implementation would not do normalization and will lead to bad results.
Helena: ..the normalisation option has .. no or FCD or NFC .. we can approach that way .. then we are all covered .. let the interchange decide whether that content needs to be processed one way or the other.. i.e. another option to say that normalisation is a possibility
Joachim: That is what I would intuitively expected from the features, may be it is better to explicitly state it.. I am not against your proposal. We already have normalization in the size restriction module ..there we have non-NFD/NFC values
Helena: .. That’s currently not reflected in the write-up.
Joachim: That’s a valid point .. it shouldn't be difficult to add this to the proposal.
Kevin: Good feedback. ..will update the proposal with Ryan for TC consideration
DavidF: It is good to bring it again to the TC, I wouldn't mind if it was added to the SVN as well. Do you have any other issues?
Helena: The only other issue is about double space. Yves also raised this issue.
DavidF: Would you follow up with Ryan?
Helena: This is already reflected in the Yves comments.
DavidF: I really like to see this module in the SVN by the end of week. Normalization is kind of stronger, double space is minor.
Kevin: We'll do our best to get this by end of this week.
Joachim: In the proposal there is an idea of using CRC32 ..but it is not easy to know what CRC 32 really means..I propose to add a pseud- code to distinguish between them .. How to address this issue as a TC?
DavidF: In general, we shouldn't point to standards that are not available royalty free
Joachim: There is also a RFC with a sample implementation in C .. this one refers again to ISO, ITU-T V.42. The latter is freely available .. it covers lot more than CRC 32
Bryan: We don’t have any interest at the moment - requested to submit as a proposal to the mailing list.
Joachim: I emailed Ryan - but will also post it to the email list.
Bryan: Hope it will not be difficult to bring this one to conclusion. Fredrick has sent length and size restriction Docbook files.
DavidF: I confirm this worked fine and it is printed and seems completed.
Bryan: I will change the status to done. Any update on the R36?
David: This is done.
Bryan: I will leave that to feature owner to update the status in the wiki.
(R41) Reference Language in matches module
DavidF: It is there. I will be doing the changes for more complex match suitability
Kevin: I'll ask Ryan to update the wiki
DavidF: How to move with the Committee Draft? What are the approaches - 1) vote on the whole thing as a one specification and 2) voting on core separately and each of the modules
Proposes a straw poll: yes, no (no abstain) on the whole specification
Bryan: I second.
DavidF: This is not ballot, but an informal straw poll.
Asanka:No, Yves:No, DavidW:() DavidF:(..) Helena:No, Joachim:Yes, Kevin:Yes, Lucia:Abstain Shirley:Yes Tom:Yes, Uwe:Yes.
=== III/ Sub Committee Reports
DavidF:
..In Rome, recruited the plenary keynote speaker proposed by the P&L SC .. the person should accept .. waiting for the final conformation.
..got FEISGILTT slot in the main conference ..1 hour slot .. 20 mins should go for XLIFF .. SC started working for content for this.
..FEISGILTT is the official pre-conference of the LocWorld .. managed to get a link to our call for papers in the main conference web-site.
..Still looking for sponsors.
..SC working on interesting proposals, discussions panel ideas .. wants to be more practical this time.
..Kevin proposed to presents a comparison between XLIFF 1.2 and XLIFF 2.0 .. Ryan and Fredrick has been proposed for this talk and Ryan has confirmed.
ACTION ITEM: Create a wiki page to publish logistic information for symposium.
=== IV/ Current Business
Bryan: We have been forwarded a note from OASIS admin. that we have a comment from xliff/comment list regarding inline mark-up in the XLIFF 1.2 specification.
..Somebody from the inline sub-committee would be appropriate to respond to the comment in the XLIFF-comment list. We need to be responsive to the comment list.
DavidF: Across is one of the major end to end TMS ..finally working on XLIFF 1.2.. it is strategic to answer.. Appeals Yves to do that .. I'd like to recruit Across to take part in the XLIFF symposium ..
=== V/ New Business
None.
-meeting adjourned-
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Bryan Schnabel
Sent: 18 March 2013 16:48
To: xliff@lists.oasis-open.org
Subject: [xliff] Groups - Event "XLIFF TC Call" added
Submitter's message
Note: The scheduled time is US Eastern time. Please note the US has already switched to daylight savings time, but Europe has not. If you are calling from Europe, please note the call will start an hour earlier for you.
-- Bryan Schnabel
Event Title: XLIFF TC Call Date: Tuesday, 19 March 2013, 11:00am to 12:00pm EDT Please join my meeting. https://www1.gotomeeting.com/join/905529225 Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. France: +33 (0) 182 880 780 Germany: +49 (0) 892 2061 159 Spain: +34 911 23 0850 Sweden: +46 (0) 852 500 612 United Kingdom: +44 (0) 203 535 0611 United States: +1 (773) 945-1031
Audio PIN: Shown after joining the meeting Meeting ID: 905-529-225
Agenda I Administration (0:00 - 0:10) II XLIFF 2.0 (0:10 - 0:45) a. If we expect XLIFF 2.0 to be a pure exchange format or if we also expect it to be usable for direct native processing? Many features will be incompatible, for example segmentation changes. ..that would not be an issue if we expect tools to convert into own format and export result of processing back to XLIFF. But could be an issue if processing is done directly on XLIFF 2. Match type and subtype (Yves, Ryan) https://lists.oasis-open.org/archives/xliff/201301/msg00025.html C. Mailing List Summary a. DavidW comment on Resource Data Module https://lists.oasis-open.org/archives/xliff/201302/msg00009.html
a. Latest in thread https://lists.oasis-open.org/archives/xliff/201303/msg00014.html 3. dF sanity check of translation candidates module (DavidF, Yves) https://lists.oasis-open.org/archives/xliff/201303/msg00003.html 4. Propose we add @name to <group> (Bryan) https://lists.oasis-open.org/archives/xliff/201303/msg00024.html D. Conformance criteria E. Charter (see above ballot) III Sub Committee Reports (0:45 - 0:55) IV Current Business (0:55 -->) V New Business
Owner: Bryan Schnabel |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]