Hi all, sorry for the delay.
I just finished editing the packed meeting minutes from 20th May.
Thanks to Asanka for excellent and detailed record. I spent a lot of time on it as several important Admin moves depend on these minutes, so we want them as accurate and detailed as possible, as mentioned in the meeting.
I move that the minutes pasted below become the meeting minutes of record.
When seconded today, the dissent period will lapse by Thursday 29th May 2014, NOON PDT.
-DF:
- Symposium meeting will not count towards voting eligibility
B:
- Goals:
-- get us oriented re the 60 day public review of XLIFF 2.0
-- prepare for official OASIS membership ballot - after 5th of July
- We have a number of editorial/administrative points to discuss in the meeting and an update from the P&L SC.
DF:
- Verifying attendance: more than 10 voters out of 13 voters
- In attendance: Helena Chapman, Shirley Cody, Tom Comerford, Fredrik Estreen, DavidF Filip, Ryan King, Lucía Morado, Yves Savourel, Bryan Schnabel, Joachim Schurig, DavidW Walters, Asanka Wasala, [11 out of 13 voters]
- Regrets: Uwe Stahlschmidt
B:
- Moving to agenda item 1.b
- Approving meeting minutes of the last meeting: Yves seconds. No dissent.
- Moving to agenda item 2.0
- 2 emails from Chet:
-- announcement of 60 day public review has begun
-- follow up by Chet, informing us that he sent the announcement
- July 5th - end of public review
- At the conclusion, we'll have 2 weeks for OASIS members to vote yes or no to move to the next stage: "OASIS standard"
- Inviting TC members' primary representatives to cast ballots in favour of the standard
- Moving to agenda item 2.b - Request to create XLIFF 2.1 templates
DF:
- This is not very formalised in the OASIS process;
- I just wanted to make a call for dissent that I am going to request the template for XLIFF 2.1 in this meeting.
- We know that 2.0 was designed to allow rapid releases; so better to request the template earlier than later.
- Kevin's idea - release minor versions every year;
B:
- Do you want people to have this discussion now?
DF:
- if I hear no dissent, I will ask for the template from Chet;
B:
- Is there any timing issues? I mean re 2.0
DF:
- It is totally independent; it is another standard basically; it does not depend on what and when happens to 2.0;
DF:
CALL FOR DISSENT:
B:
- Any dissent?
DF:
- The new spec 2.1 will be filled on the same principles as 2.0, proposing features on wiki etc.; we just need the template to formalise the new
devlopment with the TC admin.
B:
- OK, no dissents, you have the blessings of the TC to request the template;
- I will create a new tracker page, with the same methodology that we used for XLIFF 2.0 to have ideas brought to us via mailing list/comment
list; assign owners, exercise reviewing proposals, accepted or rejected features etc.
F:
- If we aim to release XLIFF versions every year, we have to be pretty careful and make sure they are not incompatible standards.
DF:
- That's the idea of 2.x vs. 3.0
- one of the unspoken assumptions of 2.0 always has been that every 2.x won't break backwards compatibility.
- no radical changes in minor releases;
B:
- Is it perhaps appropriate for us to formalise that proposing any XLIFF 2.x additional features or modules or updates shall not break backward
compatibility - any features/modules that potentially break backward compatibility needs to be reserved for XLIFF 3.0
DF:
- We actually did approve a charter clarification that says this, it did not become public as this type of motion needs a special majority
ballot.
- I propose we take the wording of the already informally approved Charter Clarification and request a special majority ballot, and if it goes
through, then it becomes official and public
- It is important; we shouldn't have an outdated TC Charter. Our Charter should be up to date as the membership ballot on 2.0 is close.
B:
- Different between rechartering and charter clarification is critical
DF:
- Rechartering would kill the TC and it is a very complicated process; rechartering is not an option and we decided way back to go for
clarification.
B:
- Better to have the clause that distinguish rechartering and charter clarification.
DF:
- You must not change scope;
- If you change your scope then you must recharter.
- We are not changing scope, we keep continuity of the committee.
B:
- may be the wording for the proposal request to special majority ballot should take that into effect;
DF:
- we say it is charter clarification; it is not rechartering, as it is not changing scope, everyone can download the docx from the svn;
we had this discussion about XLIFF 2.X and XLIFF 3.0 back in 2012/2013, we actually have it in the clarified charter:<reads the info from the
clarified charter>
[
XLIFF TC plans to continuously work on minor versions numbered 2.x, eventually 2.x.y. Minor versions numbered 2.x will be produced by adding
modules. Minor versions numbered 2.x.y will be produced by correcting minor issues.
Should significant changes to the core be required as result of industry developments, creation of a new major version will be triggered.
]
- We changed only very little; it basically just bringing the text up to date with 2.0 and further developments, similar to clarification around
1.2.
B:
- This covers us and I like it.
DF:
- I don't know if we want to have a discussion about the charter clarification, it was unanimously approved last February
- The important thing is that I am making it now a special majority request
- I move to approve the TC Officers requesting that TC Administration hold a Special Majority Ballot to approve the charter clarification
contained here:
B:
- I second.
DF:
- Roll call (normal simple majority roll call):
H: YES, T: YES, F:YES, DF: YES, R: YES, L: YES, Asanka: YES, Y: YES, B:YES, DW: YES, J: YES
- Unanimously decided to request special majority ballot for charter clarification.
B:
- moving to 2.c media type registration
DF:
- We requested a template (OASIS fron matter) for the IANA registration because if we didn't do that, it would slow down the candidate OASIS
standard.
- We approved the media registration template in a text form - we did it on 28 Feb 2014;
- We approved the text version, and I copy pasted it into the Docbook template, technically we could send this to the public review...
- In the meantime, the published version of xliff 2.0 we reference in the approved registration template is csprd03 version which is slightly
different, and it requires this change in the registration template; this is basically changing the reference from csprd03 to cos01 that is now
under public review - this will bring the media template up to date;
- I already prepared the updated version of the template;
- whenever we have committee spec draft for a work item, we send it for public review .. This is also the case with this media type registration
template.
- We can try and submit this to IETF for the provisional registration as soon as it become cs01. The provisional flag will be set to "NO" in the
final version, but we plan to merge the very final version with XLIFF 2.1.
- The only change to the approved text version is that I updated to the latest version, i.e. candidate standard 01, are there any other questions
or discussion?
B:
- No
DF:
- I move that the TC approve
control/browse/wsvn/xliff/trunk/xliff-20/xliff-media-v2.0-csd01.html as a Committee Specification Draft and designate the html version of the
specification as authoritative.
At the same time, I move that the TC approve submitting the thus created csd02 for a 30 day public review as csprd01.
B:
- I second.
DF:
Ballot:
H: Yes, T: YES, F:YES, DF: YES, R: YES, L: YES, Asanka: YES, Y: YES, B:YES, DW: YES, J: YES
11 votes (unanimous) to send this media registration template to initial public review
B:
- two agenda items left:
-- registration fragment id prefixes
-- comments for cos01
Y:
- When we worked on the fragment ids, we used prefixes for the different namespaces; the mechanism should be working not only for core and
modules but also for extensions; the idea is to make sure that people using an extension, have unique fragment id prefixes that they can use as
well; the only way to ensure this was as we discussed was to register prefixes, there is nothing in the spec how it is done; it only says that TC
has a process to do it.
- need to set up the process and make sure registered prefixes can be published easily; it shouldn't be complicated;
- page to describe how do you do registration - sending an email to comment list or the TC, something official that is permanently archived, and
some place where people can access the prefix, preferably auromatically via SW.
B:
- each prefix should have a link?
Y:
- each prefix should associate with a namespace uri
- people should avoid using conflicting prefixes
DF:
- namespace URI is owned by the submitter, not the TC
- TC only hosts the register
Y:
- yes
DF:
- I agree - process can be published as a note; we could maybe appended it to the registration template; there are a few options how to do it;
it would be a good idea to include as an appendix of 2.x.
B:
- timing is critical, people will need to be able to register their extension prefixes as soon as they start using the 2.0 standard.
Y:
- I will send an email with the full proposal.
R:
- is this just for namespace uri prefixes or is this also for prefixes that need to be defined for sub-state and sub-types?
Y:
- just for the fragment id
- does not affect name spaces of modules or extensions;
- but most likely a good idea to use the same prefixes for private values.
R:
- I think so too.
DF:
- We could have a note as a part of the process saying that it is advised to use the same prefixes for private values.
Y:
- Agree
DF:
- It can be one page
Y:
- Exactly
DF:
- We can discuss this later
Y:
- Technically, there is absolutely nothing that forces us to publish the whole process
DF:
- If someone reads 2.0, they will realise they need to register their extensions prefixes with TC, it is natural to write to the TC or comment
list.
Y:
- They'll be going to TC page; they will find the link
- it would be great if we could have a form
- we should be able to register something within a day
F:
- we don't won't something fully automatic because of spambots
Y: good point
B:
- we can do it on a wiki page, even the tc homepage
F:
- I don't think there will be a huge inrush for registering prefixes
- if we can have a form - we guarantee that we process them first come first serve or in batches or in meeting ...and add them to the registered
list
B:
- next step is to look for an email from Y.
- anything else on the fragment id prefixes?
- remaining agenda items: 2.e and 2.g -> comments that we received so far during the review of cos01
- 2.e - intro. method for dealing with comments
- 2.g - method to address comments
- moving to 2.e
- so far we have 301, 302, 303 submitted by Yves, not substantive, editorial changes;
- has anyone been tracking these issues?
DF:
- 300 is fine, 302 as well;
- 301: change of defaults seems potentially substantive to me;
- if it requires changes in schema, then we cannot do it, Y, can you explain?
Y:
- I don't think it requires changing the schema;
- need to add missing explanation ...
DF:
- Is it an informative note?
Y:
It is a change of text, when you specify what the default is. It is contextual and so cannot be expressed in schema. It is kind of obvious but
better to explain.
B:
Proposed changes:
F:
Agree.
Y:
- concern is on wording of the explanation; explaining it is tricky
DF:
- I don't understand the example part.
Y:
- can you come up with a better explanation?
DF:
- F is the ideal owner for this one.
F:
- I can take that one.
B:
- We need this in place before July 5th.
DF:
- Actually we need to resolve all comments before the next meeting, June 17.
F:
- I will try to come up with a formulation..
DF:
- I hope that we won't be getting more comments beyond this or so - there is one coming about glossary module
- We can take decisions (17th of June)in the next meeting;
B:
- shall we talk about translation candidate issue?
df:
- As far as I understood (302) the spec was talking about backslash;
Y:
- it is a just a typo
DF:
- It is changing the term or the character?
Y:
- Changing the character in one place in the text.
DF:
- I can implement it.
- 300, 302 are very easy. I can make them. I can call for dissent for these?
- I hear no dissent, so I will implement them.
Y:
- Translation candidate is also editorial. problem is that there is always a default value, we had the same in core..
DF:
- Agree
Y:
- Wording needs to be changed
DF:
- Can I have dissent for 303?
BS:
- No dissent, DF to fix;
DF:
- why not to add the glossary issue in real time so that we can have it in one batch..
- are there any other issues?
Y:
- don't know;
DF:
- we can resolve the glossary formulation on the mailing list between meetings.
B:
- any new business?
- concluding agenda item 4
- moving to agenda item 3, subcommittee debrief.
DF:
important links for FEISGILTT coneference and XLIFF Symposium:
home
reg
Speakers:
Program:
B:
- Any info on registrations so far?
DF:
-we have an interesting audience, selcet if small, we have interesting people coming from outside.. But we still need to drive more registrations
through social media buzz.
B:
- any questions?, comments?
- Next meeting will be in Dublin (will not count towards voters eligibility as it will be public), the next regular meeting will be in 17th of June.
- Meeting adjourned.
[meeting minutes END]