RE: [xliff-inline] Teleconference - Nov-9-2010 - 14:30 UTC

[Yves Savourel <ysavourel@translate.com>]

XLIFF Inline Markup Subcommittee Teleconference Summary
Nov-9-2010


Action item summary:

ACTION ITEM: Christian to try to get an initial definition for "what we code in the XLIFF content".
ACTION ITEM: Andrew to research invalid XML chars representation in other formats (not necessarily translation-related).
ACTION ITEM: All to work on ideas for how to represent native data (inline or not, etc.)


=== 1) Admin

Minutes of previous meeting:
http://lists.oasis-open.org/archives/xliff-inline/201010/msg00005.html

Presents: Yves, Dimitra, Asgeir, Andrew, Arle, Milan.


=== 2) Discussion: Requirements

Requirement working page:
http://wiki.oasis-open.org/xliff/OneContentModel/Requirements

We had several action items:

Three were simple edit tasks. They have been done:

-- ACTION ITEM: Asgeir to enter the new wordings in the wiki for 1.7
-> Done.

-- ACTION ITEM: Yves to update 1.9. with clearer wording.
"Must be able to associate each code of the source with its corresponding code in the target"
-> Done.

-- ACTION Item: Asgeir to add the following guiding principle:
"Wherever possible, data categories or representation mechanisms from other standards should be considered. For example: ITS, RDF, etc."
-> Done

The last action item is the wording of a definition:

-- ACTION ITEM: All to try to come up with a definition for the concept that encompasses original markup, accelerators, stuff that is not in the original. basically; what we code in the XLIFF content.
-> anyone?

Nobody had any proposal for this.
ACTION ITEM: Christian to try to get an initial definition.



=== 3) Topics we may need to tackle first:

We addressed backward compatibility last meeting.
The two other items to address are:

a) conformance

Yves: It seems conformance should be tackled by the TC has a whole.
We can simple expression processing expectations in our draft and if need to be, depending on the TC discussions outcome, we can adapt them to be part of the conformance or not.

All: fine with that.

b) methodology to write the document

Yves: As for the methodology to write the document: The TC has decided to go with Docbook but does not have template yet.
We can easily start our draft in the wiki and adapt it to Docbook when a template becomes available.

All: fine with that.



=== 4) Design/Implementation

The page here: http://wiki.oasis-open.org/xliff/OneContentModel/Comparison
Is a start for the discussion.

The group had most of the meeting time spent on discussing the Option A and B in the wiki.

Yves presented option A.
Main aspect to storing the native data in attribute rather than element content.

One possible issue is preserving whitespaces. One possible solution would be CDATA attributes, or escaped values.

Andrew and others added that using attribute values may be less practical in many aspects: (size limit, visually less readable, etc.)
There is value in having readable codes.

Asgeir noted that when source is used the native data is less relevant.
Arle noted that having no native data was not a good option in TMX as some native data may be different between source and target.
In some Asian languages for example bold is represented with different codes.
Keeping things optional is the answer.

Andrew suggested to keep separate two concerns:
a) storing native data inline or not
b) paired codes vs. start/end codes
Also: the use of a displayable text (inline) may help in having the native data out of the way too.


We also discussed option B (use of ITS):
Milan, Dimitra, Arle were favorable to that: use standards when they are available.
Yves was concern with tools not able to deal with different namespaces (but that's a tool issue)
Andrew, Asgeir noted that if ITS was used in XLIFF document, we may have to ensure it could be processed as ITS-annotated XML.

ACTION ITEM: All to work on ideas for how to represent native data (inline or not, etc.)


We discussed invalid characters
Yves talked about text-based escaping vs. element. Text-based escaping is less intrusive.
Arle noted that element was nice because it's more visible.
Andrew wondered about how other applications dealt with that.
From old research from Yves; they don't.
Qt TS offers a <byte> element for this, but that's all.

ACTION ITEM: Andrew to research invalid XML chars representation in other formats (not necessarily translation-related).



=== 5) Any Other Business?

None.

Yves: Maybe we could slide the meeting time a bit now that our time zones are more compressed.
Will follow by email.

Next meeting will be Dec-7

-end