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