[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff-inline] XLIFF Inline Markup Subcommittee Teleconference - July-10-2012 - Summary
XLIFF Inline Markup Subcommittee Teleconference - Summary Every second Tuesday of every month at 14:00 UTC 7:00am PT, 8:00am MT, 10:00am ET 3:00pm London, 4:00pm Berlin Teleconference meeting place: https://www1.gotomeeting.com/join/408998929 Meeting ID: 408-998-929 You can use the following US phone number, or the VOIP option provided by GoToMeeting: Dial 630-869-1010 Access Code: 408-998-929 Present: Alan, Fredrik, Yves, Jungwoo, Leave of absence: Andrew Latest draft is here: See http://tools.oasis-open.org/version-control/svn/xliff/trunk/xliff-20/xliff-core.pdf === Confirming F2F main changes with members who couldn't attend the F2F -- Dropping original data storage inline. Original data would be stored only in <data> See https://lists.oasis-open.org/archives/xliff-inline/201206/msg00009.html Alan: will check with team. Like approach. Jungwoo: no additional coments. Fredrik: main issue was pc could be used only when storing outside. Cause outside store for some case or not for others. -- canOverlap attribute New attribute to indicate whether the original code of an inline code can overlap or not. See https://lists.oasis-open.org/archives/xliff-inline/201206/msg00010.html Alan: no comment. Fredrik: explains the use cases in more details For example: This <i> is <b> overlapping</i> spans.</b> With attribute we can change the representation but never lose the info. Jungwoo: what about canOverlap='no' for pc? Fredrik: means it's also no for <sc>/<ec> and then provide info that the code can't be overlap even when using <sc>/<ec>. -- composite values for the type attribute Something like this: type ::= <category>['|'<subcategory>] <subcategory> ::= <authority>'-'<value> Would allow a fixed set of categories and user-defined ones See https://lists.oasis-open.org/archives/xliff-inline/201206/msg00011.html Alan: seems to make sense. Why one attribute then, instead of two. Jungwoo: thought about category part: main type basically. 2 attributes would be ok. Fredrik: no strong opinion. Maybe second attribute may get less used. Extra process is simple enough. But 2 ok as well. Fredrik: what about the way to define the sub-category? authority-value looks fine. Could re-use this e.g. for size restriction. Yves: Should we use namespace? Fredrik: means nothing in attribute values. But ':' could be better separator. Jungwoo: sub-category will have maintenance issues Alan: ':' would be fine. -- using <sm>/<em> for non-well-formed <mrk> Instead of using multiple <mrk> we would use the same system of starting/ending standalone tags: See https://lists.oasis-open.org/archives/xliff-inline/201207/msg00001.html Alan: simplification is good. Like it. Easy to change range. === Bi-directionality details Changes for bidi markup. See thread starting at: https://lists.oasis-open.org/archives/xliff-inline/201207/msg00003.html Yves: no need for attributes in segment and ignorable Fredrik: and the case of matches. We can get the default values from unit because Match is always in a unit. Yves: done implementing this, except for inline codes. === Annotations representation ACTION ITEM: yves to work on implementation. -> in progress ACTION ITEM: Yves to edit the draft to reflect the sm/em change -> waiting for confirmation of consensus -> can move forward now. === Elements and Attributes Names Time to start choosing final names for the inline markup. See spreadsheet here: https://docs.google.com/spreadsheet/pub?key=0Av8I1YVQlYmsdEwtZ0VEVmo5Y0ZLTndEcUlFMzZnZmc&output=html Either enter suggestion in your column (add one if needed) (ask for the link to the editable table if you don't have it any more, or post an email with the suggestions) === Namespace We need to decide to which namespace the content markup should belong. - same as the core namespace - one separate namespace (but still belong to the core) - several separate namespaces (e.g. codes still belong to the core, but not annotations, etc.) Fredrik: hard question. From tech viewpoint separate ns part of the core is more intuitive. From user view: single namespace is easier. Alan: both view point make sense. May separation is artificial Jungwoo: users would prefer same namespace in core. === Any other business Fredrik: length restriction may affect inline codes as well. Will have proposal before vacation. -end
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]