XLIFF February 5, TC Call Summary

Here are the meeting minutes, recorded by Asanka. Sincere thanks to Asanka.

Bryan:

Present: Victor, Helena, Shirley, Fredrik, Ryan, Kevin, Jung Woo, Yves, Joachim, Uwe, DavidW, Asanka

Regrets: Tom, DavidF

- meeting format has been optimized following the feedback from Kevin.

- Fredrick seconded the meeting minutes.

- First item: review approved features of XLIFF 2.0

- Going through each of the features and asking owners whether the feature indeed is "done".

- done = entry in the DocBook for the specification (that DavidF can compile) and Tom has enough information to work on the XML schema

- feature spotlight -> allocate some time from the meeting to allow people to talk about their features

- Ryan volunteered to most of items of the mailing list summery (and also for the feature spotlight).

- conformance criteria and charter discussion postponed due to the absence of DavidF. No subcommittee reports either (unless no ad-hoc reports from SC members).

- Upcoming: LocWorld + XLIFF Symposium

New Business:

Fredrick:

- proposes new agenda item to discuss - how we view XLIFF 2.0 as entirely as an exchange format

- If we expect Xliff 2.0 to be a pure exchange format or if we also expect it to be usable for direct native processing? Many features will be incompatible, for example segmentation changes. ..that would not be an issue if we expect tools to convert into own format and export result of processing back to xliff. But could be an issue if processing is done directly on xliff

Feature Tracking Review:

(Y29) Yves: I think it is done.

(Y30) Yves: Outside of OASIS..

(B31) Bryan: Done. There is a DocBook contribution made in SVN. Follow up with Tom to see whether he is satisfied with the specification to be implemented in the schema.

(Y32) Yves: I think it’s done. Helena: Agree.

(J33) Joachim: I have no idea. I am there due to inherited ownership. I need to review (action item).

(Y22) Yves: last discussed 2 wks. ago. Pretty much in agreement. Need to double check whether everything is in the spec. (action item)

(B26) Bryan: done. submitted DocBook spec. follow-up with Tom (action item)

(D17) Bryan: Marked as done. DavidW:<not clear>

(B25) Bryan: done & has a DocBook entry.

(A9) Helena: done - confirmed. Came to agreement in the email list.

(Y20) Yves: DavidF wanted to add something. Bryan: keep the status as DONE and follow-up with DavidF.

(Y27) Yves: done.

(F34) Fredrik: done and it should already be in the spec.

(Y8) Yves: it’s done, discussed during the last face-to-face meeting.

(Y7) Yves: done.

(C3) Yves: We should be ok. DavidF may have one or two small comments. It needs to be reviewed. Not completely done, but it should be ok. Bryan: Give DavidF month and a week time. (March 10th)

(D15) Bryan: March 10 as the deadline for DavidF. He may change it.

(R43) <skipped for later discussions>

(F35) Fredrik: March 5, 2013 as the 'done' date.

(R36, R41) <skipped for later discussions>

(R37) Ryan: not much to discuss. Deferred until the next call. will discuss via the mailing list. (action item)

Moving to next Agenda Item - Item B - Feature Spotlight:

Ryan:

Binary Data Module (BDM)

- A decision made during the call that we had in December was to split out the BDM into two:

1) Encapsulate referencing a file at the file level

2) Referencing an embedded binary blob at the unit level

- to address various processing needs of the binary blob at the unit level, it was suggested that we have a custom mime-type registry maintained in the OASIS site.. that explains how to read and write or process that binary blob.

- Had some internal discussions @ Microsoft as well as with other interested parties about maintaining the custom mime-type registry, processing binary blobs etc. ..then decided to drop that portion of the module and just focus on 'referencing an external file at the file level'.

- provide a standard mime-type (e.g. image or xml) that could be the mime-type of the reference file and that file would be referenced by the URL from the resource data module.

- idea is that having that mime-type would provide some sort of interoperability (e.g. if I have an image or xml file, user agents would be able to tell what that file is about). However, if I decided that I wanted to enrich my external XML resource file with may be data that will need to be done for resizing or repositioning of a control that contain text in the XLIFF, I could do that in any processing tool linking a text in XLIFF to my binary data within my resource using custom attributes/extensible attributes in the resource data modules. See mailing list discussions.

- moving right direction for the binary data module (feedback received from Joachim, Helena, Yves)

- planning to have DocBook spec. ready by the end of February. Like to hear feedback from the others.

Yves: when you gave the example of linking the text unit with the reference element in the file, you used a separate namespace as well. it would make sense may be to have actually that namespace to be the one of the resource module.

Ryan: I used different a namespace for those attributes .. for linking would not necessary be a part of the resource module.

Yves: Why? can understand the editor being something else. But why referring to the resource data need? to be in different namespace?

Ryan: .. could definitely have it as a part of the module namespace, .. not sure whether an attribute can be defined for a module, that lives outside ??? module (i.e. lives in a core element), if that is fine, then no problem defining resource ID as a part of the resource data module

Fredrick: it should be fine for modules to define attributes in existing core elements

Yves: agree.

Ryan: fine. that will help user agents to map a string to an external file. (e.g. screenshot for reference).

Helena: whether resource ID would be optional or mandatory?

Ryan: it would definitely be optional.

Helena: that would be better.

Bryan: no objections - for modules to have attributes in existing core elements

Fredrik: e.g. length and size restriction module already have its attributes in core elements

Ryan: Change Track Module

- no feedback on the mailing list. Gave an overview of the module.

- originally it was designed change tracking on elements: source, target and notes.

- idea was to store author, data/time stamp, when these elements were changed, and ability to store previous strings (source/target) or notes

- Structure: top element = change track, next element = modified, part of that element would specify who the author was, date/time stamp and change. modified element contains two elements: current - to hold the current string and previous - to hold the previous string

- Helena made a comment regarding the resource data module: would there be change tracking in the resource data module? that needs to be discussed.

- requested to review the email.

Fredrick: had a quick look at this. it looks like you are only storing empty elements. It is better to make it either optional or mandatory to store the current value in the current element so that you can detect whether a tool that does not support change tracking has actually modified the source/target/note

Ryan: current element containing the current value will be duplicating that element.

Fredrick: yes. that’s why I proposed it must be made optional using a flag or so. benefit: detect whether untracked changes made by tool that does not support the module and you can revert back to the latest tracked version.

Ryan: original reason ... because string is already there in source or target element. but I can see your point on that.

Joachim: not against copying the string. Actual increase on the transmission of data is little.

Fredrick: checksum is also good.

Ryan: whether current element is optional or actual text is optional?

Fredrick: depends on the use case.. <couldn't follow due to some interruption>

Ryan: to follow-up Fredrick offline/

Fredrick: Second point: interesting to capture XLIFF metadata like 'state' etc. to see the metadata evolution (i.e. adding a few extra attributes into current and previous elements).

Helena: different opinion: in general I like not to include process related metadata within the XLIFF.

Ryan: I think Fredrick meant already existing XLIFF attributes.

Helena: if you were referring to existing attribute values, I am ok with that.

Fredrick: .. was only referring to capturing existing XLIFF metadata (i.e. attributes related to the text)

Ryan: to follow-up offline with Fredrick.

Ryan: Number 3: reference language, quite a bit of discussion in the list.

idea: to be able to have an attribute in the matches module that specifies ..<couldn't follow up> the match as the reference match and then have the ability to specify an XML: lang attribute that does not equate with the source target element of the document, ...gives an example use case.

- mostly in agreement on this

- wanted to know who owns incorporating it to the specified matches module <not sure about this!>

Yves: action item to do it

Fredrick: An option would be let Ryan to do it himself.

Ryan: happy to do it.

Helena: .. wants to re-open this. Personally dislike this and seems to be the only one who has problems with this. highlight the issue: no restriction on the number of reference languages (and this proposal leads to a container model)

Shirley: .. doesn't understand why it makes much of a different whether to have single reference or multiple reference languages .. describe similar use cases.

Helena: current examples only discuss CAT translations. we are not talking about using XLIFF for spoken language translation (& for multimedia content) - gives examples to illustrate the complexity involved.

Meeting adjourned.

xliff message