OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-inline message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - Mar-13-2012 - Summary

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:



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:



<mrk [id='id'] type='type' [value='some value'] [ref='someId'] [translate='yes|no']>...</mrk>

<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:


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


Related email: http://lists.oasis-open.org/archives/xliff-inline/201109/msg00005.html


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.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]