← Prev in month ← Prev in thread
Next in thread → Next in month →

Groups - Segmentation Proposal Review modified

From
<>
Date
2005-04-08T10:19:22+00:00
ID
Thread
Groups - Segmentation Proposal Review modified
Segmentation Proposal Review has been modified by Mr Tony Jewtushenko*

Date:  Tuesday, 05 April 2005
Time:  04:00pm - 05:00pm GMT

Event Description:
One-off OPTIONAL meeting to review and discuss Segmentation Subcommittee's proposal to the TC:

1. Call one of the MeetingPlace phone numbers: 
From the AMER region dial: * 1-888-967-2253 * +1-650-607-2253 
From the APAC region dial: * +61 2 8817 6100 
From the EMEA region dial: * +44 118 924 9000 

2. Enter the Meeting ID (805534) followed by the # key 

3. If the organizer has not started the meeting you will be:

	a. Asked to speak your name followed by the # key 
	b. Placed in the waiting room on music hold until the organizer starts the meeting. 

If the organizer has started the meeting you will be: 

	a. Asked to enter the Meeting Password (030543) 
	b. Asked to speak your name followed by the # key

Agenda:
Proposal for Segmentation Notation in XLIFF (Magnus):
http://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/200503/msg00002.html

Initial Feedback:
http://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/200503/msg00005.html
http://www.oasis-open.org/apps/org/workgroup/xliff/email/archives/200503/msg00004.html

General review of the proposal
Debate the approach.
Examine specific recomendations.

Minutes:
1/Role Call:  no quarum rules required - this meeting was optional and didn't count towards voting eligibility.
Attendees: Tony,  Magnus, David Pooley, Florian
Apologies: Doug, Peter, Christian, Andrzej

2/General review of the proposal
Only David Pooley responded with feedback requiring a response from the Segmentation Sub Committee.  Magnus responded initially with detailed information in these two emails: 
http://lists.oasis-open.org/archives/xliff/200503/msg00004.html
reply from Magus-> http://lists.oasis-open.org/archives/xliff/200503/msg00007.html

http://lists.oasis-open.org/archives/xliff/200503/msg00005.html
reply from Magnus-> http://lists.oasis-open.org/archives/xliff/200503/msg00008.html

3/Debate the approach:  
It was agreed that there wasn't a need to debate the approach only resolve some specific concerns raise in feedback.

4/Examine specific recommendations: 

We discussed David's feedback,  with resolutions,  and Magnus' resplies and summarized actions as follows: 

Issues raised in this mail -> http://lists.oasis-open.org/archives/xliff/200503/msg00007.html

[1] whether the new attributes are mandatory or optional on the  and  elements.

Resolution: all new attributes are OPTIONAL.  Will modify the specification to reflect this.

[2] As equivalent-translation is being set at the  level, this seems to impose the setting through all  elements. Is this a good idea?

Resolution: Good point and all agreed that this is not an ideal situation.  Will review meeting notes to understand why this was chosen and if no good reason can be determined we will move equivalent-translation to target.

[3] Where did you envisage the manipulation of the elements and attributes taking place?

Resolution:  the manipulation / segementation of elements will be in the "translator" domain, not at the extraction filter domain.  This means that segmentation will either be performed by the Editor tool or possibly automated segmentation process.  It was agreed that this would be documented in the proposal and XLIFF spec.

[4] A minor point, I know, but is it really necessary to have such long attribute names?

Resolution: the attribute names will be shortened as follows: "segmentation-source" -> "seg-source",  and "equivalent-translation" -> "equiv-trans"


Issue raised in this mail: 
http://lists.oasis-open.org/archives/xliff/200503/msg00005.html

Main issue related to how to represent segmentation of non-clonable  elements.  It was suggested that using  element as per SRX would address this problem but on closer inspection introducing the element didn't resolve the problem with 's.  It's suggested that this matter be addressed by documentation with examples of potential problems and how to avoid them.  Magnus' reply will provide the discussion of the issue and an example to add to documentation ->  http://lists.oasis-open.org/archives/xliff/200503/msg00008.html

5/Next Steps:  

Once the issue of "equiv-trans" at  v.  level is resolved,  and changes to proposal are made,  the revised proposal will be redistributed to the TC.  Target date for revised version to be published is 12 April.  TC will vote on formal ballot to accept/reject the proposal at the 19 April monthtly teleconference.


View event details:
http://www.oasis-open.org/apps/org/workgroup/xliff/event.php?event_id=7567

PLEASE NOTE:  If the above link does not work for you, your email
application may be breaking the link into two pieces.  You may be able to
copy and paste the entire link address into the address field of your web
browser.
← Prev in month ← Prev in thread
Next in thread → Next in month →