[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Teleconference - Feb-08-2011 - 15:00 UTC - Summary
XLIFF Inline Markup Subcommittee Teleconference - Summary Present: Yves, Andrew. Regrets: Milan, Christian, Lucia === 1) Admin Minutes of previous meeting: http://lists.oasis-open.org/archives/xliff-inline/201101/msg00002.html === 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) Invalid XML character representation ACTION ITEM: Yves to research 1.1 status Done: http://lists.oasis-open.org/archives/xliff-inline/201101/msg00003.html and thread. Yves: It seems 1.1 may not be the good solution. Andrew: Agree. in our case we handle them by using inline codes (for some filters). No specific guideline from XML people (besides that an XML file is for text) Maybe a recommendation saying those characters should be treated as inline codes would be enough. --- 2.2) Native data representation in inline Thread on the native data representation: http://lists.oasis-open.org/archives/xliff-inline/201011/msg00001.html ACTION ITEM: Yves to summarize the new options in the wiki and others to add/correct afterward. Done: http://lists.oasis-open.org/archives/xliff-inline/201102/msg00000.html Andrew: Maybe general principle A self-contained TU is valuable. So maybe using the 'global' notation would be ok only if other things are already breaking the TU self-containment. Otherwise using inside representation would be better. ACTION ITEM: Yves to post email to lists on possible options to get feedback. Andrew: Examples of "nasty" cases may help us. ACTION ITEM: Andrew to post some "nasty" examples. --- 2.3) Other codes/features Need to start selecting some representation of each requirements, add definition text, etc. See wiki for some of the mrk-related discussion. http://wiki.oasis-open.org/xliff/OneContentModel/Comparison Outcome of the discussion: It seems that making mrk into different more specialized elements would be beneficial for validation, clarity and modularity. One note: In some areas, the progress of the SC may be dependent on the progress of the TC, for example on segmentation or TU self-containment. ACTION ITEM: Yves to post a note on the TC list to point out the need for progress in those areas. === 5) Any Other Business? - none. - Next meeting will be March-08 at the new time (15h00 UTC) -end
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]