[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff-inline] Inline Markup Teleconference - Summary
XLIFF Inline Markup Subcommittee Teleconference - Summary Presents: Yves, Arle, Fredrik, Andrew, David-W, Christian, Bryan The summary of our main items is here: http://wiki.oasis-open.org/xliff/OneContentModel/Requirements Draft is under SVN, here: http://tools.oasis-open.org/version-control/svn/xliff/trunk/inline-markup/ (this will be replaced by DocBook version soon) === 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> Yves had an action item to start test implementation. -> done. This leads to some question about overlapping representation. http://lists.oasis-open.org/archives/xliff-inline/201110/msg00022.html - what to do with isolated tag and non-well-formed annotation? -> possibly use <as>/<ea> type elements Andrew: if annotation has a reference we need to make sure split one can be identified as the two parts of the same. Fredrik: think it's a problem to have several mrk pointing to a reference if that reference is not 'above' [<mrk ref='qq'></mrk>][<mrk ref='qq'></mrk>] For mrk without reference: we would base merging on type, etc. May need specific flag to indicate two adjacent mrk are not the same: e.g. two terms separated in source but adjacent in target Other questions: http://lists.oasis-open.org/archives/xliff-inline/201110/msg00027.html - what about translate info without other info? Should type='trans' be mandatory? <mrk type='trans' translate='no'>...</mrk> Or <mrk translate='no'>...</mrk> Without type would be cleaner. Can we have <mrk value='stuff'>...</mrk> Fredrik: we can enforce this or not depending on schema 1.0 or 1.1 Will have to decide which one to use. A solution could be to have a default value for type (generic/no-meaning) Arle: That gets kind of tough from a validation standpoint to require a value attribute everywhere except with a specific attribute. <mrk type='generic' value='stuff'>...</mrk> Arle: I don't really like that because the meaning isn't clear. I suppose ok if other tools aren't required to understand it. Fredrik: disallowing would be ok too. Should rely on schema as much as possible. Possibly a question for TC: Schema 1.0 or 1.1. David: Should we limit ourselves based on what the schema can do or not? There is a trade off there. Arle: Not everything needs to be checked in a schema. Dave is correct. Then the question is of the cost (not checkable) vs. benefit (doing something good) What about RelaxNG, etc.? Arle: RelaxNG can do this, but you'll find opposition from some in the TC to using it. RelaxNG combined with Schematron is *very* powerful. I like it a lot. Fredrik: both more mature than XML Schema 1.1 ACTION ITEM: Yves to bring this topic to the TC. === Type of inline codes: A by-product of trying to resolve question about keeping or not <pc> led us to make a mapping table between 1.2 and 2.0. (Appendix in http://tools.oasis-open.org/version-control/svn/xliff/trunk/inline-markup/) - need to handle isolated code (vs non-well-formed) -> possible isolated attribute for <sc>/<ec> and rid replaced by id for isolated <ec>. How to map <it>? Fredrik: isolated attribute would be fine. Would be nice to keep link between the two markers across units. Yves: to try to implement it. - do we need crc? Andrew: don't see it useful at element-level. Fredrik: same Arle: same. David: didn't see it used. Yves: same. Christian: see this in broader context: no algorithm specified, so can't really work with it across tools. Consensus is that it's not needed in inline markup. Andrew: Christian point valid for the whole document as well. Arle: If it really matters to someone, could this be created as a (publicly documented) extension? I don’t see this as something that obviously belongs in the core. - do we need assoc? Fredrik: not in <x/> by the way. Arle: For this one, we might want to ask the committee at large. Bryan: remember talking about it with Magnus. Andrew: we don't use it. ACTION ITEM: Yves to ask to TC if anyone is using crc or assoc and report on current status for those. === 1.16. Inline codes should have a way to store information about the effect on the segmentation See http://lists.oasis-open.org/archives/xliff-inline/201109/msg00005.html Skipped. === Keeping <pc> or not? Will need a resolution soon as it affect other decision like <mrk> vs <sa>/<ea>. Currently we have: <ph>, <pc>, <sc>/<ec> Fredrik: cloning of non-clonable <g> (or <pc>) is not really doable Andrew: yes, you need a lot of logic to re-create it. === 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 Skipped. === Representation of added codes Need to clarify use of duplicated code. e.g. why not re-use same code? (See http://lists.oasis-open.org/archives/xliff-inline/201110/msg00021.html) Skipped. === Representation of editing hints Need to have notation for 'permissions' Last discussion: http://lists.oasis-open.org/archives/xliff-inline/201106/msg00003.html Fredrik: Discrepancies in clone attribute in 1.2 All should have that info in 2.0 And 'removable' Current permission we thought about: 1: a code can be deleted 2: a code can be replicated 3: a code can be moved out of its original order 4: a code can be moved outside its original parent span Andrew: #4 could be complex without much value Fredrik: yes, especially if supplied to all types of codes David: what is a "Parent span"? Yves: e.g. <pc> in: <pc> <ph/> </pc> Andrew: Need to avoid complex hierarchies. Maybe #4 could be drop if needed Christian: is it for the 'code' or specific attributes inside. Fredrik: applies to the whole element. Christian: which tool would set that info? Fredrik, Yves: extraction filters would do that. Andrew: info from tool with specific knowledge mapped to file-type agnostic format. Christian: this is also related to rep added codes. Fredrik: arbitrary tool can only re-used existing cloneable tags. Specialized tool may do more. ACTION ITEM: all to think about representation for hints. === Any other business None -end
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]