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] | [Elist Home]

Subject: [xliff] XLIFF Teleconference Minutes - Tuesday,14 Jan 2003

Agenda item 1: Roll Call
Present: Mark Levins, Gerard Cattin des Bois, Shigemichi Yazawa, Tony Jewtushenko, Matt Lovatt, Christian Lieske, Doug Domeny, Yves Savourel
Apologies: Peter Reynolds, John Reid
Absent: Jonathan Clarke, Mirek Driml, Ian Dunlop, Enda McDonnell, David Pooley, Bryan Schnabel, Reinhard Schaler, John Corrigan

Agenda item 2: Review of previous meeting minutes
Unanimously accepted as true record.

Agenda item 3: Review of all remaining open issues listed in the tracking report. (Refer to http://lists.oasis-open.org/archives/xliff/200301/msg00007.html)
Issue 3 in tracking document, 'New elements, "default" and "defaults"'
Shigemichi raised defaulting attributes such as 'ts' and 'tool', how different defaults could be specified for the <source> and <target> elements and how extensions to the XLIFF spec might be defaulted. Yves suggested allowing any descendant attribute of <group> to be defaulted within a <group> element. Mark countered on this on the basis that John Reid's proposal outlined the most common and most necessary attributes for defaults as opposed to overloading the group with everything.
In response to discussion, Tony suggested possible addition of defaults such as 'tool' (attribute of <alt-trans>) to group. Mark argued against this on the basis that values in elements such as <alt-trans> did not need to be defaulted since they were not likely to be set at the creation/origination time of the XLIFF document and were only added during the translation cycle of the document.
Gerard motioned for a vote that John Reid's proposal should be accepted with the proviso that additional default attributes might be added to the <group> element at next week's meeting. Matt seconded this and the motion was unanimously passed.
Action required: Agenda item to be added for next week's meeting - Discussion & agreement on additional default attributes in <group>

Issue 6 in tracking document, 'reformat Element revisited'
Gerard suggested dropping this feature due to the time it will take though this was met with opposition from the Oracle TC members, and Mark Levins on the basis of the value added and existing requirements.
Yves raised the following points:
       Getting the feature right the first time.

        The changes that must also be made to the <alt-trans> element
        Whether discussion had occurred around the migration path from XLIFF 1.0 to 1.1
        Whether the required changes constituted calling the new spec XLIFF 2.0
There was much discussion over the benefits of each of Matt's proposals (in essence, sibling elements to <source> and <target>, or child elements to <source> and <target>) with various advantages of each option pointed out, from backwards compatibility to neatness, to shortcomings with <alt-trans> and workarounds for these.
Shigemichi/Yves stated opinion that Matt's second option more closely approximated what he would have expected the feature to have looked like if it had originally been implemented and backwards compatibility was not at issue.
Shigemichi questioned which way XLIFF might be handled when information such as coordinates might be specified in multiple ways, i.e. in both the old attribute fashion and with new elements. It was generally agreed that the specification must specify precedence.
Gerard asked which was more important, the feature or backwards compatibility.
In the following discussion item Doug raised a point relevant here - if new elements such as <coord> were directly added as children to <source> and <target>, they would affect translation matching applications which expected the whole content of the <source> or <target> to be textual or marked-up text.
Tony called for one more week of active discussion on this subject so that agreement on whether this feature will be included in principle, in the 1.1 specification.

Issue 11 in tracking document, 'TextContent Extensibility'
Yves mentioned that Doug's recent email clarified most of the problems he foresaw with allowing extensibility within <source> and <target>s.
Doug stated problems size problems without using extensions. Yves pointed out alternate approach to generating XLIFF from HTML/XHTML which might negate the requirement. Doug asked if a 'best practice' document existed for using XLIFF with HTML/XHTML. None exists currently but this was earmarked for future work after XLIFF 1.1 publication.
Shigemichi pointed out that if XHTML extensions were added then further standards developments might also require support and that there might be requests for native support for other existing formats, for example RTF.
Mark stated that extension points within text content might also adversely affect translation matching tools such as translation memory and machine translation which only expect the limited markup tags currently used by XLIFF.
Gerard moved for a vote on deferring TextContent Extensibility until the next revision of XLIFF, Matt seconded and the motion was passed unanimously.

Agenda item 4: Spec Draft review (XLIFF 1.1 draft 2b http://lists.oasis-open.org/archives/xliff/200301/msg00009.html)
Due to meeting overrun & loss of quorum this item and the rest of the agenda was deferred until the next meeting. Tony Jewtushenko requested that each member of the TC to review the draft specification during the coming week and to provide feedback directly to Yves.

Agenda item 5: Schedule of remaining work
Not discussed.

Agenda item 6: Discussion and response to recent xliff-comment regarding resizing of RC  type data within XLIFF
Not discussed.

Agenda item 7: Any other business
None tabled.

Next meeting - Tues,  21 Jan 2003, 04:00PM  Europe/London/Dublin  / 08:00 AM PST

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

Powered by eList eXpress LLC