Teleconference - Apr-12-2011 - Summary

XLIFF Inline Markup Subcommittee Teleconference - Summary April-12-2011  === 1) Admin  Minutes of previous meeting:  http://lists.oasis-open.org/archives/xliff-inline/201103/msg00001.html
Attendees: Yves, Christian, Milan, Lucía, Andrew, Bryan.
=== 2) Discussion Requirement working page:  http://wiki.oasis-open.org/xliff/OneContentModel/Requirements  Markup options working page:  http://wiki.oasis-open.org/xliff/OneContentModel/Comparison
--- 2.1) Native data representation in inline  Thread on the native data representation:  http://lists.oasis-open.org/archives/xliff-inline/201011/msg00001.html
ACTION ITEM: Christian to contact Felix Sasaki and Richard Ishida about additional suggestion about XPath/XPointer/CSS/etc. Done, see email here:  http://lists.oasis-open.org/archives/xliff-inline/201103/msg00002.html
Christian: So far I only got a private reply from Felix.
ACTION ITEM: Andrew to post some "nasty" examples on inline codes. Pending.  Andrew: got the example, just need to post it.
See also email from David in TC list:  http://lists.oasis-open.org/archives/xliff/201104/msg00025.html  (item #3)  Yves: It seems all David's notes are in synch with our approach.
--- 2.2) Cloning, deletion, addition of inline codes.  Current requirements list need of feature to clone and add inline codes. See email here:  http://lists.oasis-open.org/archives/xliff-inline/201104/msg00000.html
Andrew: Seems replication and deletion are the two main info Order and allowed-outside-nesting may be less used  Should we use one attribute or several?  e.g. <g canDelete='yes' canClone='yes'> or <g perm='canDelete;canClone'>  Using one may prevent some abuse. Yves: We may need to think about how verbose the code may become with several attributes.  Andrew: Right defaults may help in reducing the verbosity.  Christian, Andrew: This could also be define at a higher level (e.g. file) By context for example. Bryan: almost like ITS mechanism. Yves: then possible copy/paste-type issues: info is lost when taken out of context.
--- About representation of new codes:  Two types: replication of existing code and brand new codes.  Replication:  <x id='1'> text <x id='1'> allowed in 1.2 may not be good in 2.0 (unique ids) <x rel='1' id='2'/> could be for 2.0  Yves: Is missing code notation fine?  Andrew: Mapping from 1.2 to 2.0 needs to be taken into account. Bryan: We may not be able to be backward compatible all the time Here: we are talking about mapping: how to 'convert' a 1.2 file to 2.0 Maybe tool to do the conversion?  Should be allow 'abstract' new codes? e.g. <g ctype='bold'>text</g>  Bryan, Andrew: yes Yves: how the filter know the native data in the case of <g>-type notation? Andrew: -> List of allowable new codes generated by the filter. Christian: +1 More generally: Maybe a list of constraints. Bryan: should be optional. Some use cases where xliff is used by itself only. Yves: optional would work.  Andrew: Such list is for the tool, maybe it should be defined outside of XLIFF?  Christian: What about the process/tool chain? e.g. some components should not do this type of modification --> Will need examples from Christian to illustrate this.
--- 2.3) Span/markers -type elements  XLIFF 2.0 needs specific elements rather than a generic <mrk>. Let's start defining those elements, based on the requirements.  Examples: <mrk mtype='term'>term</mrk> <term>term</term> <span its:term='yes'>term</span>  Example of categories:  - term - protected content / non-translatable - comment - auto-localizable content (date/etc.) - transliterated content - in general: some kind of 'annotation'  Luciía: need to make sure several annotations can be assigned to the same span of content.  Christian: -> We need to look at semantic web for inspiration. It's the same as the description of a demarcated resource. Semantic web offers ways to do this.  ACTION ITEM: Christian to provide background info on semantic web. Possibly examples.
=== 3) Any Other Business?  - Next meeting will be May-10 at 14h00 UTC
-end