OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xliff] Groups - Event "XLIFF TC Call" modified


Thanks Joachim, I thought it was you who made us aware of the Pandora's box of storage defaults during the discussion.
I do not think that the draft implies you propounded it..
Whom should I attribute this and do I miss some other of your contributions to the discussion?
Or should I just make clear that you mentioned is only as option without proposing it?
Please let me know..
@Others, who feel misrepresented, please shout, so that the minutes can be made as accurate as possible..

Rgds
dF

Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie


On Tue, Apr 9, 2013 at 10:35 AM, Schurig, Joachim <Joachim.Schurig@lionbridge.com> wrote:

Hi,

 

while I participated in the discussion, I was definitely not making the two statements below attributed to me (considering normalization for the normal XLIFF content).

 

I actually think there should not be an attribute about normalization in the XLIFF core. In my opinion it makes sense to have it in length restrictions (because they refer to the storage format) and to a lesser extent in validation, but not in core. If you expect or need a specific normalization in your document, apply it.

 

Actually, even the normalization attributes in the size restriction module do not require the content be stored in that normalization – which would also be difficult as the same content could have e.g. NFC for their storage size applied and NFD for general size restrictions.. it’s only used to know which calculation about sizes to apply.

 

But in general: thank you David and Filip for the reconstruction of the discussion – that’s not an easy task!

 

Regards,

Joachim

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip
Sent: Montag, 8. April 2013 23:00
To: Bryan Schnabel
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] Groups - Event "XLIFF TC Call" modified

 

Hi all, please find attached and pasted a draft of the minutes of our meeting on April 2. Since no one was scribing during the meeting.

Bryan and myslef made an effort to reconstruct the main points of the discussions.

@Fredrik, @Helena and others, please have a closer look than usual if anything needs amendment/clarification

 

I Administration (0:00 - 0:10)

 A. Roll call

Present: Victor, Helena. Shirley, Tom, Fredrik, DavidF, Ryan, Kevin, Peter, Yves, Bryan, Joachim, Uwe, DavidW

Regrets: Asanka, Lucía

 B. Approve previous meeting minutes, 19 March 2013 https://lists.oasis-open.org/archives/xliff/201303/msg00042.html  

Move to accept: Bryan; Second: DavidF; no objections

[Fredrik: DavidF is not marked as present in last minutes, can he second?

Bryan: David was late a few minutes, this needs to be fixed on kavi.

DavidF: I was late due to the time change, but I myself sent Asanka’s minutes to the TC list after checking them briefly. Will fix attendance.]

II XLIFF 2.0 (0:10 - 0:45)

 A. Review Approved Features in WIKI (https://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking ) (0:10 - 0:20)

  1. Take a quick look at statuses

  2. See if any features need “live” input from TC

 B. Feature Spotlight

1.      How we view XLIFF 2.0 as entirely as an exchange format (Fredrik)

N/A

C. Mailing List Summary

  1. R37: Revised Validations Module proposal (Ryan) https://lists.oasis-open.org/archives/xliff/201303/msg00034.html

Conversation largely between Ryan, Helena, Fredrik, DavidF:

Fredrik explained that the core spec defines standard normalization form (NFC) for any content comparison operations.

Fredrik: I believe that the validation module should simply refer to the core.

Ryan: Fine with me

Helena: Fine with me

DavidF: The core in fact does not prescribe any sort of normalization for the document, it just uses NFC to define sameness of content.

Helena: The question is whether there is a normalization default and BTW I believe that NFC is the right thing here. And also whether this can be overridden where it makes sense.

Joachim: But the core does not say anything about normalization when storing into an XLIFF document.

DavidF: Exactly, the default normalization for content comparisons (but not for XLIFF document storage) is defined, and IMHO the two modules (validation and length restrictions) are the only places where the user might need to be able to override the default. It is possible in length restriction, just that the default probably should not be “none”. If the validation only refers to the core default, it will actually not provide means for override.

Fredrik: For length restrictions, “none” makes sense provided that no normalization was done on the XLIFF content. I could specify NFC as the deafault.

Bryan: This takes too long, we will not have time for other items.

DavidF: I think that the opinions are quite close. I’d like to make one proposal and if it does not carry, this will need to continue on mailing list.

The proposal is that NFC is an XLIFF wide default (for comparisons, not for storage) and the two modules should provide means to override this via an attribute.

Fredrik: The normalization could be a core optional attribute.

Joachim: We need to think if the XLIFF document needs a default for storage.

Helena: I need to think of a use case where this needs to be overridden for validation

DavidF: OK, let’s continue this on mailing list. The basic issue to resolve is whether XLIFF needs a storage default or if we are OK with having a default for comparison purposes only. Depending on this, the modules will or will not provide means to override the default.

a.       Helena comment on Resource Data Module https://lists.oasis-open.org/archives/xliff/201303/msg00056.html

N/A

  2. Change Track Module [pending CRC32 discussion] (Ryan) https://lists.oasis-open.org/archives/xliff/201301/msg00032.html

a.       Latest in thread https://lists.oasis-open.org/archives/xliff/201303/msg00014.html

N/A

  3. dF sanity check of translation candidates module (DavidF, Yves) https://lists.oasis-open.org/archives/xliff/201303/msg00003.html

DavidF: I implemented the consensus today.

  4. Propose we add @name to (Bryan) https://lists.oasis-open.org/archives/xliff/201303/msg00024.html

Bryan explained the reason; asked for any objections; nobody objected; proposal passed.

DavidF: I implemented the consensus today into the spec.

  5. How do we refer to an external skeleton in XLIFF 2.0? Propose we add @href to skeleton (Bryan) https://lists.oasis-open.org/archives/xliff/201303/msg00049.html

Bryan explained the reason; asked for any objections; nobody objected; proposal passed.

DavidF: I implemented the consensus today into the spec. The PR says that skeleton must be empty if and only if ahref is specified. I believe this captures the consensus reached on the mailing list.

[The Editor’s Draft specification of skeleton was shown online.]

D. OASIS Next Steps

  1. How to proceed to the CD Full Majority Vote and the Committee Specification Public Review Draft (CSPRD) Full Majority Vote. (DavidF)

     a. Objective is to be in a public review or to have completed a last public review by June.

David explained the need to know of any objections now. Asked Bryan to send a note that (in a nice way) compels voting members (or any member) to express dissent.

AI @Bryan: Send out Call for Dissent.

DavidF: We should try and have the first Full Majority Vote https://www.oasis-open.org/policies-guidelines/tc-process#dFullMajority on the Editors’s Draft https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff-20/xliff-core.pdf moving to CD and consequently to CSPRD in the meeting on April 16, 2013.

In OASIS unlike in W3C ANY changes made to the CSPRD require a subsequent Public Review. Each of the reviews requires a Full Majority Vote The subsequent public reviews need only to be open for 15 days, whereas the initial must be open for at least 30 days.

Bryan: It is important to get the initial long one out of the way and make nimble changes in series of the subsequent reviews. This is also how other TCs do it.

DavidF: Special Majority Vote https://www.oasis-open.org/policies-guidelines/tc-process#dSpecialMajority will not be required until after the last public review when no more changes to the spec will be required. This will bring us to Committee Specification, which then goes for the OASIS wide ballot.

It would not be practical to run the process for core and each module separately, so please express dissent with any part of the spec prior to next TC meeting, as follow up to Bryan’s call for dissent.

As editor, I believe that the spec is largely in good shape, Tom will need to adapt schema to the minor changes I introduced today following the resolutions reached before the Easter Break.

The normalization discussion is important but will result in only small parametric changes in core, and/or the validation and length restriction modules. Other than that the spec is in good shape.

Bryan: Please do not hold your yes vote hostage, because you haven’t formed an opinion on a module. Let us adopt a sub-committee approach, as the TC has delegated inline issues to the Inline SC, so people who cared participated in module discussions. The discussions were robust and led to consensual solutions. Let us send to OASIS and the World a message by approving the CD unanimously.

  2. Conformance criteria

N/A

E. Charter (Bryan to update site)

N/A

III Sub Committee Reports (0:45 - 0:55)

[This was covered before D. OASIS Next Steps]

DavidF explained that the CFP for 4th Symposium is still open, till April 5, 2013 and SC still looking for interesting submissions and sponsors.

DavidF: F2F will take place on MSFT premises in central London, on June 10, 2013, the day before XLIFF Symposium (track of FEISGILTT on June 11-12, LocWorld preconference).

AI: @All F2F participants to e-mail their name and company (for the check in procedure) to Kevin and DavidF by May 31, 2013.

F2F webpage https://wiki.oasis-open.org/xliff/F2F2013 has skeleton agenda. Can form TAXI (rental car) parties to go to the meeting place from your hotel.

The meeting will be very important for addressing Public Review comments. Please subscribe and participate!

IV Current Business (0:55 -->)

N/A

V New Business

N/A

Meeting adjourned

 

 


Dr. David Filip

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

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

 

On Tue, Apr 2, 2013 at 2:53 PM, Bryan Schnabel <bryan.s.schnabel@tektronix.com> wrote:

Submitter's message
Added OASIS Next Steps agenda item.
-- Bryan Schnabel

Event Title: XLIFF TC Call


Date: Tuesday, 02 April 2013, 11:00am to 12:00pm EDT
Description

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
Access Code: 905-529-225
Audio PIN: Shown after joining the meeting
Meeting ID: 905-529-225


This meeting counts towards voter eligibility.


Agenda

I Administration (0:00 - 0:10)

 A. Roll call

 B. Approve previous meeting minutes, 19 March 2013 https://lists.oasis-open.org/archives/xliff/201303/msg00042.html  

II XLIFF 2.0 (0:10 - 0:45)

 A. Review Approved Features in WIKI (https://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking ) (0:10 - 0:20)

  1. Take a quick look at statuses

  2. See if any features need “live” input from TC

 B. Feature Spotlight

  1. How we view XLIFF 2.0 as entirely as an exchange format (Fredrik)

C. Mailing List Summary

  1. R37: Revised Validations Module proposal (Ryan) https://lists.oasis-open.org/archives/xliff/201303/msg00034.html

    a. Helena comment on Resource Data Module https://lists.oasis-open.org/archives/xliff/201303/msg00056.html

  2. Change Track Module [pending CRC32 discussion] (Ryan) https://lists.oasis-open.org/archives/xliff/201301/msg00032.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 (Bryan) https://lists.oasis-open.org/archives/xliff/201303/msg00024.html

  5. How do we refer to an external skeleton in XLIFF 2.0? Propose we add @href to skeleton (Bryan) https://lists.oasis-open.org/archives/xliff/201303/msg00049.html

D. OASIS Next Steps

  1. How to proceed to the CD Full Majority Vote and the Committee Specification Public Review Draft (CSPRD) Full Majority Vote. (DavidF)

     a. Objective is to be in a public review or to have completed a last public review by June.

  2. Conformance criteria

 

E. Charter (Bryan to update site)

III Sub Committee Reports (0:45 - 0:55)

IV Current Business (0:55 -->)

V New Business

 


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



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]