[xliff-inline] XLIFF Inline Markup Subcommittee Teleconference

XLIFF Inline Markup Subcommittee Teleconference 2012-03-13

----------

Present: Fredrik, Bryan, Jung, Alan, Ingo

Regrets: Yves (Fredrik will chair the meeting) Leave of absence: Andrew

Introduction, new members: Jung, Alan

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

=== Annotations representation

(req 1.5: Must allow to associate spans of content with metadata)

Current proposed representation:

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

<ms />Text to annotate <me />

See section "2.5.3 Annotations" in draft for an early draft.

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

Alan: 2.0 to allow re-segmentation

Jung: important to be able to mark as un-translatable. What categories should be available.

Fredrik: up for discussion

Alan: will it be extensible

Fredrik: The extensibility is still under discussion

Bryan: yes still on TC

Fredrik: Any thought around the different style of marking annotations? Start / end or spanning?

Fredrik: Recently discussed third option.

Fredrik example:

This <pc>is a</pc> sample

This <pc>is <mrk>a</mrk></pc><mrk> sample</mrk>

This <pc>is <ms />a</pc> sample<me />

Alan: good with example. Good with XML structure.

Jung: Need to think how the tool will mark the content.

Fredrik: both <mrk>’s would share some id

Alan: more markup might reduce leverage

=== Validation/compliance

ACTION ITEM: Christian to bring back the validation tool question to the TC.

=== Representation of editing hints

Need to have notation for 'permissions'

Discussion on the semantics:

See Fredrik's email http://lists.oasis-open.org/archives/xliff-inline/201202/msg00021.html

and following emails.

Fredrik, introduce point. Discuss need for forth hint about change of nest level. Thoughts, questions?

What do you think about need for a fourth hint? Is the reordering hint enough or do we need a new.

Alan: sounds sensible. Need on segment level vs document level.

Fredrik: discussion so far on segment. Gives examples of edit ops that need hints.

Bryan: reason for not introducing it

Fredrik: we previously found it was not needed.

Bryan: not against reintroducing it. No downside.

ACTION ITEM: Fredrik to try with fourth hint and send out processing expectation summary.

ACTION ITEM: Yves to add section for this in specification.

-> Not done yet.

=== Bi-direction 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

Any input from new member? How do you handle bidi text?

Jung: Unicode control and XML. Prefer the tag approach.

Alan: No direct experience with the problem. First impression is to use tags.

Bryan: we generally try to re-use existing standards. This should be considered in this context.

Action item: Yves to ping w3c again.

-> Not done yet.

=== Codes and effect on segmentation

(req 1.16: Inline codes should have a way to store information about the effect on the segmentation)

Fredrik: intro on subject. Does any one have experience with problems?

Alan: some experience with segmentation. Not sure if this is the right direction. Will be hard to do without full solution. What is the use case?

Fredrik: Segmentation is discussed at TC level. This is the part the inline support.

Alan: could be hard to implement

Fredrik: Agree

Fredrik: One solution would be to have an optional attribute that hold a string of characters to give the segmentation engine instead of the code.

Bryan: Does this really need to be handled / is there a need for this from LSPs.

Fredrik: Not high on our agenda.

=== Representation of added 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?

No discussion on this point.

=== Face-to-face:

June-13/14 in Dublin seems to be working for enough.

Yves will work on the details soon.

=== Normal meeting time:

We need to check on how many people are on the west coast now.

And see if the normal time of 7am is fine or not.

Bryan: on the west coast. Better with 8 am

Fredrik: CET ok now and +-1 hour

Ingo: GMT, current time good

Jung: GMT, happy with current time

Alan: Pacific time. Ok with current time

Introduction new member: Ingo

=== Any other business

No, other business to discuss.

-end

xliff-inline message