[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] Propose these as official meeting minutes for the 18-February-2014 meeting (RE: [xliff] Groups - Event "XLIFF TC Call" modified)
I propose that the meeting minutes here (https://lists.oasis-open.org/archives/xliff/201402/msg00033.html), are the official meeting minutes for the TC meeting held 18 February 2014. I ask that somebody please second. I will then call for dissent. If none comes by 25 February, I will consider these the minutes of record.
I know we’ve been taking this route for approval for the past few times in order to accommodate our PR and still hit our target date for XLIFF 2.0.
I am using this method for these minutes in order to allow David to "request a standalone OASIS template for the IANA media type registration template/form as a separate work product [mandating dF to fill out this admin form https://www.oasis-open.org/resources/tc-admin-requests/work-product-registration-template-request to that effect]. "
This way he will not have to wait until the first Tuesday in March (when the meeting minutes would have otherwise been approved) to take this important step, and help to ensure we do not delay XLIFF 2.0.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Bryan Schnabel
Sent: Friday, February 21, 2014 11:41 AM
Subject: [xliff] Groups - Event "XLIFF TC Call" modified
Event Title: XLIFF TC Call
Date: Tuesday, 18 February 2014, 11:00am to 12:00pm EST
Please get the dial in information from our private Action Item here:
This meeting counts towards voter eligibility.
I Administration (0:00 - 0:10)
A. Roll call
B. Approved meeting minutes, 04 February 2014 https://lists.oasis-open.org/archives/xliff/201402/msg00010.html
C. Yves added support in the latest snapshot of Rainbow
(okapi-apps at http://okapi.opentag.com/snapshots/)
for extracting to XLIFF v2 and merging back.
II XLIFF 2.0 (0:10 - 0:45)
A. Public Review III is underway https://lists.oasis-open.org/archives/xliff/201402/msg00015.html
11 Feb 00:00 GMT - 25 February 23:59 GMT
B. Evaluate comments collected on the tracker for PR-III for substantive vs. editorial (https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20submitted%20comments%20tracker)
C. Do we add the media type registration for XLIFF 2.0 to the spec? Or do we add it as a standalone template? (https://lists.oasis-open.org/archives/xliff/201402/msg00027.html)
III XLIFF 2.X? 3.0? (0:45 - 0:50)
A. Freeze on Feature Tracking wiki? Or queue proposed post 2.0 features there?
B. Do we have an official path for promoting custom namespace to supported core/module post XLIFF 2.0?
IV Charter (Bryan to update site)
V Sub Committee Report (0:50 - 0:55)
VI Current and New Business (0:55 - )
Meeting notes summary: (1) TC agreed to DavidF proposal that "the XLIFF TC requests that TC Admin produce for us a standalone OASIS template (front matter) for the IANA media type registration template/form as a separate work product" and formalizing the "TC's requesting a standalone OASIS template for the IANA media type registration template/form as a separate work product in the same meeting [mandating dF to fill out this admin form https://www.oasis-open.org/resources/tc-admin-requests/work-product-registration-template-request to that effect]" (https://lists.oasis-open.org/archives/xliff/201402/msg00027.html). (2) Each issue on the tracker (200 - 226) was presented to TC and ask if anyone objected to it being catagorized as editorial, not substantive. Each issue was agreed by TC to be editorial, not substantive.
- regrets: DavidF, Lucia, and Helena
- 3rd public review is underway now; started on 11th Feb and will end on 25th of Feb;
- Currently we are on track to still meet the projected date for completing the OASIS official standard for XLIFF 2.0; it coincides nicely with the XLIFF symposium.
- If we can come to agreement that we do not have any substantive changes, and if the changes are largely editorial in nature , then we will not have to have the PR IV
- People from the community are largely of the opinion that they want to have XLIFF 2.0 sooner than later
- We as a TC decide that we want to have a standalone doc for the media type registration, or if we think we need to include that in the XLIFF 2.0 spec; that would be fine, but doing so would push back our publication date;
- No sub-committee meeting today
- Moving to admin tasks:
- Roll call: Y, A, B, DO'C, DW, F, Ray, T, U, K
- 9 out of 15 eligible voters in attendance
- We've achieved quorum
F: J will join later
- Already approved the minutes of the previous meeting
- Yves added xliff 2.0 support for Rainbow (http://okapi.opentag.com/snapshots/)
- Concluding agenda item I and moving to agenda item II:
- It would be useful to evaluate the comments that we've got so far; and also let's take a look at media type registration
- Moving to II.C:
- dF has put lot of energy investigating this and interacting with OASIS admins;
Fredrik Estreen (to All - Entire Audience via Chat):
7/13 voters according to Kavi
- dF is proposing that the XLIFF TC request that the TC administrators produce for us a standalone OASIS template with front matter for the IANA media type registration as a separate work product;
- dF is not formally making a proposal with this email, but rather he wants us to discuss this during today’s meeting
-- We have two options: we can let this media type registration document live as a separate work and use that in our registration of media types
-- We can choose to include this in our spec; downside is that IANA media type registration changes from time to time; every time it changes we'd have to change our spec to reflect those changes. Tom or Yves, do you have any views on this?
- Joachim joined.
- I'm in support of dF's proposal. Is there anybody who thinks that we should embed this in the XLIFF 2.0 specification?
- i don't understand why we need to make the registration itself a part of the standard?
- I agree, I don't see any advantages including in the spec and in fact I would say that it would be harmful (according to dF).
f: If we need to publish it somehow I do agree that we should not embed in the main specification; but why do we need to publish it using a specific front matter or why do we need to publish it at all? ... Normative in some way?
- We don't want to make it normative from the spec's point of view
- If we try to hit to our projected date, we don't have to … normative ref from the spec to the registration doc
- T or Y anything to add?
- not really, like Fredrick, I am not quite sure what's the interest of adding that along with the specification or in the specification?...
- We've said that it is required to do so.
- I don't think anybody is arguing in favour of embedding this in the specification; I don't think we have a firm understanding why it requires to be a separate work product at all; ... we indeed accept dF's proposal as written and we mandate him to fill out the form as necessary
- I second.
- are there any objections?
- no objections, but I abstain; because I don't understand why we need this.
- running through the issues in the issue tracker:
- <going through the accepted definitions of the terms: substantive and editorial>
- we've so far registered 26 comments; so far my judgemental is that each of the issues has been editorial; propose to go through the issues that have been tracked so far and decide whether they are substantive or not;
-- 200: <describes the issue>, editorial, no disagreements/objections
-- 201: in contact with Ryan and in agreement with Ryan - editorial, no disagreements/objections
-- 202: editorial change, no disagreements/objections
-- 203: editorial change, no disagreements/objections
-- 204: editorial change, no disagreements/objections
-- 205: editorial change, no disagreements/objections
-- 206: editorial change, no disagreements/objections
-- 207: editorial change, no disagreements/objections
-- 208: several occurrences of uppercase XML namespace or lowercase xml namespace
F: I'd personally prefer the uppercase,
B: we need to verify in the W3C XML namespace spec, and we should choose that one
-- 209: editorial change, no disagreements/objections
-- 210: editorial change, no disagreements/objections
Fredrik Estreen (to All - Entire Audience via chat):
Example from W3C Namespaces in XML:
" An XML namespace is identified by a URI reference"
F: introduction from the namespace ... xml document
-- 211: editorial change, no disagreements/objections
-- 212: editorial change, no disagreements/objections
-- 213: editorial change, no disagreements/objections
-- 214: DO'C and Yves are assigned; is this something that you can take on?
Y: I can take it on, but you know my opinion.
B: You are referring to the fact that owner should be somebody different?
Y: not necessarily, if nobody says anything I will implement the change
b: DO'C, any feedback useful for item 214?
DO'C: will do
B: editorial change, no disagreements/objections
- Yves made further improvements to the checker
216 TC Admin Comment: editorial change, no disagreements/objections
217: editorial change, no disagreements/objections
218: editorial change, no disagreements/objections
219, 220, 221, 222, 223,224, 225} : editorial changes, no disagreements/objections
-We have consensus among the TC members that 200-225 are editorial.
- Agenda item VI: no new business.
- so far not discovered any substantive changes
- b: Joachim, you are the owner of the glossary module, not sure whether you've seen the request for clarification by Yves <describe the request>
- Y, you are asking about the translation candidate module more than the glossary module?
Y: I am asking about the consistency of two usage mechanisms, because they are very similar, in once case it is required in the other case it is optional
J: I don’t have a comment about the translation candidate module; ... nobody has seen that it is not synchronised; I've no particular opinion about the translation candidate module
Y: .. the rest on the glossary should be optional?
B: I have been ….. translation candidate module, making optional would not negatively impact; I have no objection making it optional.
Y: We need to check with DO'C; it is probably not substantive.
B: 226: editorial: assign this to dF and DO'C;
- I'll continue to update the change tracker;
- We are on track for the dates as calculated before;
- Meeting adjourned.
Owner: Bryan Schnabel
Group: OASIS XML Localisation Interchange File Format (XLIFF) TC
Sharing: This event is shared with the OASIS Open (General Membership), and General Public groups. Public Event Link
NOTE: The best way to keep your desktop calendar updated is to subscribe to the Group calendar.