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: Teleconference - Nov-14-2010 - Summary

XLIFF Inline Markup Subcommittee Teleconference - Summary

=== 1) Admin

Minutes of previous meeting:

Attendees: Yves, Lucia, Christian.
Regrets: Andrew, Dimitra.
Note: Asgeir is off the group since he changed employer. Hopefully he'll be back soon.

=== 2) Discussion

Requirement working page:

Markup options working page:

We had several action items:

-- ACTION ITEM: Christian to try to get an initial definition for "what we code in the XLIFF content".

Christian started some thoughts on defining the different terms, as a base for a definition:

We worked on a definition based on Christian's input and ended up with the following:

"The representation of inline content consists of text possibly augmented with the following type of data:
- genuine inline entities (entities which belong to the original extracted document (e.g. inline markup like "em"))
- supplementary entities (entities which supplement/augment the original; annotations that are not available in the original)
- surrogate entities to represent 'illegal characters' (characters not allowed in XML)"

Action Item: Yves to add the definition in the wiki. -> Done
Action item: All non-present to look at it and comment if necessary.

-- ACTION ITEM: Andrew to research invalid XML chars representation in other formats (not necessarily translation-related).

Andrew send his regrets. Action item still pending.

-- ACTION ITEM: All to work on ideas for how to represent native data (inline or not, etc.)

Some start of discussion on the native data representation:

- does it needs to be always attached?
- it helps for processing to have direct access (snippet of data, no need for storing the block of data, etc.)

- It's possibly that the least choice of representations we have the better interoperability we are likely to have.

- XPointer is a possibility. (See Christian's email)
- Concerns are: scalability, possibly no enough available implementations, possibly complicated to implement for CAT tools.

- Next step: draw a list of options and ask for feedback to the TC.
Possibly, after the list is reduced to several main options, ask for comments to the public.

Yves will try to get the list started.

=== 5) Any Other Business?

Next meeting will be Jan-11.


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