RE: [xliff-inline] Inline makrup Teleconference - Apr-10-2012 - Summary

[Yves Savourel <ysavourel@enlaso.com>]

XLIFF Inline Markup Subcommittee Teleconference - Summary
April 10th 2012


Present: Yves, Fredrik, Arle, Jung, Christian.
Regrets: Alan
Leave of absence: Andrew

The summary of our main requirements is here:
http://wiki.oasis-open.org/xliff/OneContentModel/Requirements

Latest draft is here:
See http://tools.oasis-open.org/version-control/svn/xliff/trunk/xliff-20/xliff-core.pdf

I've also added a TODO page to try to summarize the various issues we have left:
http://wiki.oasis-open.org/xliff/OneContentModel/ToDo



=== Annotations representation

Current proposed representation:
http://lists.oasis-open.org/archives/xliff-inline/201110/msg00013.html

<mrk [id='id'] type='type' [value='some value'] [ref='someId'] [translate='yes|no']>...</mrk>
See section "2.5.3 Annotations" in draft for an early draft.

We also need to decide on how to code annotation that are also original codes (like HTML5 translate).

See also thread about a generic pattern for annotation-type features in the TC mailing list:
http://lists.oasis-open.org/archives/xliff/201203/msg00009.html
(element vs. offsets, etc.)

-- Case of annotation is also in the original data:

For example, HTML5: <p>Text <span translate='no'>data</span></p>
A: Text <pc id='1' translate='no'>data</pc>
or B: Text <mrk translate='no'><pc id='1'>data</pc></mrk>
or C: Text <mrk translate='no'>data</mrk>

Fredrik, Arle: B seems better option.
B: more tags.
B: easier to post-process document.
Unique id in mrk to link source and target (not same id as the pc)
For translate='yes': we do need to represent it if we have nested information.
Fredrik: currently use just ph for those.

-- Representing non-well-formed annotations

Fredrik example:
This <pc>is a</pc> sample
A: This <pc>is <mrk>a</mrk></pc><mrk> sample</mrk>
B: This <pc>is <ms />a</pc> sample<me />

Comments for example can end up like that.
Arle: ms case complicates thing for common cases.
Solution A is inconsistent with sc/ec/pc
Christian: Consistency should rule the world :-)
Yves: seems we have a few more pros for B.
Will try to implement both for test.


=== Validation/compliance

ACTION ITEM: Christian to bring back the validation tool question to the TC.
Christian: done (implicitly): discussion about validator in the TC.
Any thoughts for this?

For 1.2 we have XLIFF-Checker to validate files.
But actual validations implemented by the tool are not listed

Do we need specific tool, could we use XSD 1.1? Relations between spec and need for validator?
Fredrik: for compliance we will need to validate before/after to validate transformation
Should try to validate the file itself with XSD as much as possible

Arle: Lot of work done on validation:
XSD can't validate all for format like XLIFF.

Yves: same as Fredrik.

Christian: schema based validation would be best.
Not sure if tool-based validation is needed.
Maybe providing input/output example could be a way around the need for the tool. May lead to some risks.
Maybe should consider using different schema, RelaxNG or Schematron to complement.
Arle: seems doable. TBX is an example of this.
Fredrik: XSD 1.1 is published now.

Arle: Issues with schema may be a good warning sign:
If we reach the point the schema can't validate something it may be a spec problem.


=== Representation of editing hints

Need to have notation for 'permissions'

ACTION ITEM: Yves to add section for this in specification.
-> Not done yet. But working on it.

Discussion on the semantics:
See Fredrik's email
http://lists.oasis-open.org/archives/xliff-inline/201202/msg00021.html
and following emails.

Fredrik: Seems being permissive is the best option.
Possible fourth hint for nesting.
But not sure anymore. It would help, but the added complication is justifiable.
If tool need to do complex re-ordering it would probably need to understand the native format.
Processing expectations should be limited to the simple cases.
But two tools could go beyond that.

Fredrik will post a document soon on the general topic of editing/working with inline codes.



=== Bi-directional markers

Several tools use Unicode characters in 1.2.
Goes against W3C recommendation but seems common practice.
-> need to know about other tools
-> ask for info to W3C
Sent (but not passed the W3C check yet).

Some reference material:
- http://www.w3.org/International/questions/qa-bidi-controls
- http://www.w3.org/International/wiki/BidiProposal

Action item: Yves to ping w3c again.
-> The private feedback I got was mostly 'markup is better'.
Shall we look at implementing an HTMl5-like mechanism for directionality, that would be integrated with our annotations?

Fredrik: Will need it on source/target (base direction)
On inline codes too.
Need dir for both the content and the original data, possibly.
Will need examples for those cases.

Arle: will control char be disallowed?
Big question! Will need to decide this. HTML5 allows them it seems.
Arle: may have to require the markup form.

Christian: question is also do we need to care about this?
- In term of XLIFF processing?
- In term of XLIFF rendering?
Fredrik: as programmer of editor, we do care about rendering.
Several assumption works most of the time, but not always.
Two different problems, but we probably care about both.

ACTION ITEM: Fredrik will try to come up with a markup for this.



=== Representation of added codes

ACTION ITEM: Fredrik to try to post his document about different cases for adding inline codes.

See early text in Yves' email:
http://lists.oasis-open.org/archives/xliff-inline/201202/msg00014.html
Any comment? Good enough to start putting this in the spec?

We may also want to have a section on deleting codes:
As one way to 'remove' a code can be to make its original data part of the text.

Fredrik: Things there is no good way to do it generically.
More examples/explanations in the up-coming document about inline codes.


=== Face-to-face:

The formal ballot closed with 6 yes and 1 abstain.
So we do have a face-to-face meeting in Dublin.

I'll post shortly today more info on the meeting logistics.

The last thing to decide is whether or not it should include the afternoon of Friday (morning seems to be ok).
We must decide this during this call, so people can make travel arrangements.

Arle has a 4pm flight, other may need to leave early too.
Resolution: Officially meeting on Friday morning.
It's OK to not be there in the afternoon.
But the room available for the afternoon for informal work for people who stay longer
(e.g. Yves leaves only Saturday).



=== Any other business

--- Meeting time:

Based on the discussion of last call, it seems we could move the teleconference time to 8am PDT, 9MDT, 4pm Dublin/London, 5pm CEST.

Can't move one hour later because of ULI teleconference for several SC members.


-end