OASIS Open

Bryan moved to approve minutes. Fredrik seconded. No objections

Recap of agenda by Bryan

Bryan introduced Martin Chapman, TAB member on behalf of Oracle (Oracle is on TC, so no IPR issue with having Martin as guest).

Martin introduced himself and explained that TAB (Technical Advisory Board) assists OASIS BOD

with the technical material aspect of the TC process. TC admin only review formal aspects of specs. 

TAB trying to review content. TAB wants to review 100% of publicly reviewed Committee Specification Drafts.

Martin: We are piloting the checklist that I attached to my comment (https://lists.oasis-open.org/archives/xliff-comment/201305/msg00000.html). I included the items that SHOULD be fixed in the e-mail body [fix normative and informative references as outlined in the checklist, mention 1.x in the conformance section].

dF asked Martin to clarify the structure and how to parse the TAB checklist. The understanding is that column C [necessity] signifies potential severity and only matters if the check (in coumn D) was not passed. This was confirmed by Martin.

Martin gave more detail on his review: references, conformance targets

XLIFF conformance targets are document and applications, the spec has no separate section on applications, it mostly specifies the document target. But the roundtrip requirement, that is a conformance requirement targeting applications, introduced only in the conformance section, seems to be clear and warranted.

Backwards conformance SHOULD be addressed in the consformance section.

Martin said that the spec is clearly normatively written, overall above average.

Bryan: What about UPPERCASING of normative keywords? (see https://lists.oasis-open.org/archives/xliff-comment/201305/msg00003.html)

Martin: It is not a big deal, some people work with the ISO set (which is different) and use just natural language capitalization.

dF: Uppercasing or italics? The template we received from TC admin (12 to 15 month ago) enforces italics w/o uppercasing through <glossterm> element decoration and stylesheet.

Martin: I did not pay attention to this because you are consistent, but I will double check with the TC admins if the templates are out of sync. The doc templates I am aware of do uppercase.

dF: Thanks for checking. We should be ableto uppercase via stylesheet once confirmed. 

TC thanked Martin and Martin left the meeting.

===================================

TOPIC: Resolution of Public Review Comments

===================================

Bryan: We will look now at our wiki tracker of the comments 

https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20submitted%20comments%20tracker

dF: The wiki tracker is to allow for TC collaboration, a pdf snapshot of the tracker will be saved from time to time to SVN. The final pdf with resolutions is a mandatory part to progress according to TC process. 

csprd01 is set in stone (exposed to review on OASIS servers outside our SVN), although we have a copy of csprd01 on our svn, we MUST NOT and in fact cannot chnage it. I will create tomorrow wd02, into which we will be implementing the resolutions. Editors and contributors, do not edit until you have seen my commit. In fact as of April 16, all changes to the spec MUST be based on docummented public review comments. 

Fredrik: we should create a tag/branch

dF: We have revision number references but I can create a tag for convenience.

dF to create a tag for csprd01.

dF: I propose that all unassigned comments are assigned to TC owners for resolution by next meeting.

Bryan: Sounds good

Fredrik: Owners should propose solutions on list, consensus assumed if not contested within a week or so.

Bryan, dF: Sure we will have ballots only in case consensus cannot be reached.

--------------------------------

Bryan goes through tracker, all current comments are assigned as result as follows [skipping previous assignments]:

Bryan takes 003 [fully feature XLIFF 2.0 example] (https://lists.oasis-open.org/archives/xliff-comment/201305/msg00001.html), change to editorial.

dF: where? Also it is illustrative (i.e. non-normative and hence editorial) not substantive.

Bryan/Ryan: Towards the end.

Ryan: how do you define fully featured?

Bryan: I mean each feature as tracked on the feature tracking wiki.

Ryan: There should be a full fledged example of core, then maybe one module. And then each module should have its onw, I tried to have examples in my.

-------------------

Fredrik takes 006 (https://lists.oasis-open.org/archives/xliff-comment/201305/msg00004.html)

Fredrik to drive consensus on TC list. 

--------------------

dF takes 009, 010, change to editorial

---------------------

Tom takes 011 (https://lists.oasis-open.org/archives/xliff-comment/201305/msg00009.html)

Tom to drive consensus on TC list.

--------------------

Fredrik takes 012 (https://lists.oasis-open.org/archives/xliff-comment/201305/msg00010.html)

This is just renaming attributes for consistency, normative but actually immaterial.

--------------------

Bryan takes 013

Bryan to drive consensus on TC list.

Quick update on P&L SC by dF: No major sponsor this year except CNGL.

 Spread the word, register http://bit.ly/YTDQO7, also register for F2F on June 10 by sending an e-mail to Kevin and myself.