RE: [xliff-inline] Teleconference - Oct-12-2010 - 13:30 UTC

[Yves Savourel <ysavourel@translate.com>]

XLIFF Inline Markup Subcommittee Teleconference
Summary Oct-12-2010

=== 1) Admin

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

Presents: Yves, Asgeir, Lucia, Andrew, Christian
Regrets: Dimitra, Bryan


=== 2) Discussion: Requirements

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

We had several action items:

-- ACTION ITEM: Yves to find a real example for requirement #4
--> Done, (thanks to Andrew for his suggestion of OpenXML)

-- ACTION ITEM: Arle to bring any additional requirement from OSCAR.
--> Pending. Note that the formal requirement time is done now and we are moving into actual design/implementation phase.
Active feedback/participation is still very welcome obviously.

-- ACTION ITEM: Yves to check the term used in XML specification "illegal" or "invalid", and use it everywhere.
--> Done, use "illegal".


There is one last requirement we have not gone through: #17:
There is a start of an email thread here:
http://lists.oasis-open.org/archives/xliff-inline/201009/msg00008.html

Original text:

===
When processing well-formed XML, the best practice is to process the inline XML element as an XML node, not escaped start and end points
For example, if the entire inline element is contained in the segment, this XML: 
This text is in <b>bold</b>.
It is required to be able to preserve the node, like this: 
This text is in <code name="b">bold</code>.
It should be avoided to use a start and end marker in places of the actual code, like this: 
This text is in <code native="[startBold]"/>bold<code native="[endBold]"/>.
===

After discussion the consensus was to use:
ACTION ITEM: Asgeir to enter the new wordings in the wiki.

===
When processing original markup with a span-like structure, it should be represented using a span-like element in the XLIFF inline markup, rather than using two XML elements denoting the start and end of the span. This notation allows easier XML processing and corresponds to the original structure. For example, given the following original XML content:

<img src='image.png'/> is a <b>beautiful</b> image.

We should be able to represent it in XLIFF using a markup where "<img src='imag.png'/>" is represented by an empty XLIFF element; and "<b>"/"</b>" are represented by a unique XLIFF element that encloses "beautiful".

For instance, using a representation such as this imaginary one:

<code id="1" content="img"/> is a <code id="2" start="b" end="b">beautiful</code> image.

Instead of:

<code id="1"/> is a <startCode id="2" start="b"/>beautiful<endCode id="3" end="b"/> image.
===



Christian has also sent several comments. Please, look at them and the follow-up emails:
http://lists.oasis-open.org/archives/xliff-inline/201010/msg00000.html

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.

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."



=== 4) Getting started with discussion on the implementation.

Several topics we may need to tackle first:

a) backward compatibility

Christian: Maybe could achieve backward compatibility by keeping current markup, but deprecate it?
Asgeir: This would put a lot of extra weight for the new model. (e.g. supported for paired codes, etc.)
Christian: Maybe we can make this depends on the conformance clause.
Yves: No incentive to use new codes
Christian: Examples showing how old codes are compare to new may help pushing implementer the right direction.
Andrew: No backward compatibility, but ensure we do have a deterministic mapping from old to new. Well defined migration path would help.
Christian: Except when old markup is used inconsistently. But very interesting thought.
Asgeir: Probably not possible to have backward compatibility if taking into account all the new requirements. But some sort of deterministic mapping could be possible.
Lucia: Agree with Asgeir. This is an important topic and it needs to discuss in TC as well.
Asgeir: Note that we had a TC ballot on this.
Result of the ballot was: no backward compatibility, but we try to accommodate whenever possible.


Next meeting is Nov-9.

-end