OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-inline message

[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:

Draft is under SVN, here:
(this will be replaced by DocBook version soon)

=== 1.5. Must allow to associate spans of content with metadata

Current proposed representation:

<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.

- 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:

- 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


=== 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


=== 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)


=== Representation of editing hints

Need to have notation for 'permissions'
Last discussion:

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]