Meeting minutes 19 February 2013

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

I am very sorry for the delay. DavidF and I crossed our wires and did not get these published until now.

 

Thanks to Asanka for the excellent scribing.

 

 

Regrets: Yves and Helena

Meeting minutes seconded by Joachim. No objections.

Sent out a call for feature spotlight volunteers. Nobody responded. We had a request from Fredrick last week.

II.A – Implemented changes to the Wiki – (apologies to David/Tom – doing it without consulting DavidF/Tom)

Taken a second look at the approved features and the mailing list discussions to identify which of these had made any progress, which items need to be covered.. we are doing good.. only found a handful of items we hadn’t discussed/commented before.

last week’s tradition.. if I didn’t know a date – added a default due date.  Added due date as 10^th March for couple of approved features. Owners are free to change.  Good to know the progress at a glance. Did some minor adjustments to the Wiki. Added two new fields in addition to the schema updated field and spec. updated fields. At a glance field is esp.  useful for DavidF and Tom to communicate back to us ..whether  changes have been incorporated &  whether the changes were satisfactory.

DavidF: It is useful.

Tom: Agree. Pretty useful for me to tracking everything.

Bryan:  Feature owners are requested to have a look at these updates. bottom-line.. only stuck with a handful of features now.

II.B  Features that are put into the Spotlight – Fredrick’s suggestion. Overview of the mailing list discussion.

DavidF:-

Attendance: We’ve 70% and we’ve safely reached the quorum.

Asanka, DavidW, DavidF, Jung Woo, Joachim, Kevin, Bryan, Peter, Ryan, Tom, Uwe, Victor

We have 12 voters.

Bryan:  II.B – We do not have Fredrick.

Joachim: Fredrick is in another call. Trying to get him. We could decide to push it to the next call. Helena was also interested in this topic.

Ryan: 

Notes:  Original desire was to add category attribute to notes. Originally looked into adding origin for the notes and data/time. Other suggestions – put that origin and date/time to the Change Track Module.. and that make sense. In addition to the Category, there was a request (by Frederick?) to add in Priority. So we have two new attributes in the Notes element:

1)      Priority

2)      Category

..hasn’t been much controversial discussions on the mailing list about adding those attributes.

It is just a matter of making sure everybody is ok with adding those attributes and if so having the owner of the Matches module add those.

DavidF: Did you say priority on matches?

Ryan: No. on Notes.

DavidF: Just wanted to explain.. the priority on the note was for the purpose of mapping ITS notes.

Ryan: Ok.  Also to insert an extension point in addition to the above two attributes.  Any further discussions or moving forward with the adding those 3 features?

Bryan: Any objections?

DavidW: Is this category a text/fixed list of items?

Ryan:  No.

DavidF: Are you basically suggesting a list of items for the category, for it to be useful?

DavidW: No. Just for clarification.

Ryan: Since there are no further comments – I propose we go ahead and make those 3 changes to the notes module.

DavidW/DavidF: I second.

Bryan: No objections.

Ryan: -

Reference: ..last discussion was about the need for the reference module. Few use-cases were discussed via the mailing list.

Implementation: In the matches module to have a reference attribute, to mark the match as a reference, and then to be able to have an xml:lang attribute that is different from the source/target attributes of the doc. <Explains  the implementation using an example use case>.

Joachim: I agree with the feature. But .. you might miss something for such use cases then on the glossary module, there it’s only the XLIFF source/target languages which are referred to by the terminology. Will that be a problem?

 

Ryan: <couldn’t follow>

Joachim: That’s what I was thinking. Should we consider adding an xml:lang attribute to the terminology then as well?

Ryan: That would make sense.

DavidF: Agree.

Joachim:  Should the source language also be variable? ..for a some extent then the notion of source and target of the glossary module  becomes questionable. All of a sudden you get more than two languages. Should we stick with the XLIFF source language and make an exception only for others (i.e. target)?

DavidF:-

There are two different aspects at least: use case for multilingual xliff, tried to recruited Stefan <couldn’t follow> , ..we shouldn’t try to resurrect the idea for multlingual xliff..

.. I think generally the glossary is too light weight. Too simple to play important role in data exchange in real life – I support the idea of adding reference language to the glossary..

Joachim:  It may be light weight – you could use tbx.. transport some glossary into an editor, so it is not supposed to serve all glossary purposes … idea to create a  terminology module.. I like to keeping it small  Proposal: Then we  should add xml:lang to the target terms?

Ryan: That would work. Then the proposal is for both the matches and the glossary modules to be able to use the xml:lang different from the xml:lang attribute of the target of the document.. I propose to move ahead with those changes as well.

Bryan: I second.

Victor: Are we going to constrain that to one single reference language?

Ryan: We should provide opportunity to have many. As it is today in the matches module, you can provide any number of matches <gives several example scenarios>.

Victor: Ok. My only concern is whether we are moving back to the multilingual container model.

Ryan: It constrained only for the Matches module. (i.e. Not to have multiple target languages of the document).

Joachim: Avoid by all means to have the real trans-units multiple languages – anything else doesn’t  add to the processing overheads, no problem even to have multiple languages to source in the matches.  Make sure that we don’t envision to having XLIFF as a multilingual standard.

 

Bryan: Put a note in the specification?

Joachim: That would help but..may be its over cautious.

DavidF: No. it is not over cautious. – Standardizer’s intensions should be made clear- A Note is a good vehicle for that.

Bryan:  Proposed and seconded. Any objections?

DavidF:  Did we propose and second it.. reference lang for matches for both matches and glossary or will we move with  glossary separately?

Ryan:  Included glossary as part a of my proposal statement, but we can propose it separately if we need to.

DavidF: I would rather see them separately – because they are at different stages .. if you can manage both .. I will leave it with you to decide

Ryan: I will leave it up to Joachim to decide – better to send samples/discuss further via the email list.

DavidF: It makes sense – Joachim is the owner of the glossary module.

Joachim: It makes sense to send some examples on the email list – because there might be objections, which we might need to clarify.

DavidF: Agree. Part of these issue are due to they are being in different stages.                This was brought up today for the first time and I think better to address them separately.

Ryan:-

Last item on the mailing list.. discussion on the match type and sub type.. not going to talk much about this. Yves sent an email with description of changes. I supported his changes – haven’t seen any comments contrary to his changes.  ..Going to leave with Yves as he is driving that. He has those changes ready .. but he had no time to include those –Take a look at  Yves email and comment on it.

Bryan: Any other features owners like to discuss their features?

Ryan:-

Resource Data Module: incorporated the changes that were discussed over the email list.. reviewing internally.. in the next couple of days I’ll send the document once again with the changes, then I will move to creating the DocBook files

Change Track Module: haven’t seen much feedback as yet.. during the last call it was suggested that duplication of the source text within the  current element of the change track module. As per the last week’s discussion, we could have attributes defined in a module  living in a core element. Going to follow-up the Change Track Module.. hoping to do some slight changes to the  author and time/stamp  defined attributes defined in the Change Track Module.to define them to be potentially live in a core element .

DavidF: It make sense. Saw DavidW comment on the date /time format. Are you agree with the proposed date/time format for the change track module?

DavidW: I don’t remember commenting on the date value.

DavidF: I remember there was a discussion about best practices for the date format (e.g. CLDR) . May be it was someone else from the IBM?

DavidW: I guess it was Helena or Michael.

Ryan: I haven’t seen any communication about that – but the date format is UTC format, if there is a desire to change it, email me.

DavidF: Better if IBM people can confirm the date format.

DavidW: Will pass the message to the others.

Joachim: Personal opinion: We should take care to have a restrictive date format.. check how W3C is representing date/time.. Important to consider Time Zones too.

Ryan: I used UTC , date /time + time zone – that was my proposal.

Joachim: I don’t like that too much . But can live with that.

Bryan: Time to  P&L subcommittee report and charter clarification

 

DavidF:-

Charter Clarification: there was no interest to rechartering in general. Points were minor. Not prepared to propose a ballot now. Best cause of action is to send an electronic ballet proposal before the next TC.

4^th XLIFF Symposium : LocWorld has decided to have the Symposium earlier. London is well positioned for strong attendance and it will be very close to the public review of our committee draft ..

We’ve tried the format XLIFF symposium as a part of the LocWorld + FEISGILTT,  good chance to attract a large community participation. Its in June – late spring. Planned 11^th and 12^th of June.

Format : 1^st day – technical presentations, 2^nd day –<couldn’t follow> …showing call for papers , basic web-page is up – inviting participation in the XLIFF and ITS tracks, we might have more tracks this time.

Discussions on-going with other standard owners. Here we consider the XLIFF symposium , but we need to collaborate with other standards. 

 

What is needed now? Last year we neglected to properly advertise the  F2F meeting. Propose to have it on 10^th June.. logistics not sorted yet. Encourage anyone to provide access to space in London to host the event.. symposium is a part of the LocWorld.. it will be London west hotel  .. We might need to charge for the F2F participants if we failed to find sponsorship for the space.

If we move forward with the XLIFF 2.0, June 10^th could be important for resolution of the public comments to the spec . There is a chance for a very important meeting

Looking for the sponsors for the events. A registration cost will be there- it will be reasonable. LocWorld gave significant reductions to FEISGILTT (and vice versa), Sponsoring is welcomed.. contact me regarding that.

Inform potential speakers,  program committee is setup. We can invite people specifically if you nominate.

It will be exciting if the committee draft will be on public review.

Though you are not a P&L member, you can just join for the purpose of subscribing to email updates.

Meeting adjourned.