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 - Jan-11-2011 - Summary

XLIFF Inline Markup Subcommittee Teleconference
Jan-11-2011 (1/11/11)

=== 1) Admin

Minutes of previous meeting:

Attendees: Yves, Andrew, Christian, Milan
Regrets: Lucia

=== 2) Discussion

--- Definition to add

- Action Item: Yves to add the definition in the wiki.
-> Done

- Action item: All non-present to look at it and comment if necessary.
No comments were made.
The definition is therefore done. And the item closed.

--- Invalid XML character representation

- ACTION ITEM: Andrew to research invalid XML chars representation in other formats (not necessarily translation-related).
Andrew did his action item.
Didn't find anything in the different standards. In the XML specification: it appears that XML 1.1 does supports those characters. So the solution could be to make XLIFF XML 1.1 based instead of 1.0.
Yves noted that 1.1 was possibly a dead standard rarely implemented.
Andrew noted that .NET: handled it.

Action item: Yves to research 1.1 status

--- Native data representation in inline

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

- ACTION ITEM: Yves will try to get the list started.
Done: See http://wiki.oasis-open.org/xliff/OneContentModel/Comparison#SummaryofthePossibleOptionsforRepresentingNativeData for a start of a list.


Additional pros/cons where brought up.
And various representation for the 3rd option (native data outside the segment) were discussed.

 <text id='1'>text in bold</text>

 <text><code id='1'>text in bold</code></text>

<source>/<nativeSource> and <target>/<nativeTarget> at the same level.

Another possibility would be to use two options:
- simple case could use the attribute mechanism, while more complex ones would use the "outside" mechanism.

The outside mechanism has two possibilities:

- store locally (in trans-unit or in source/target)
- store globally (in the file)

Benefits in both cases (less if outside is local)

For outside ref: local or global?
- Andrew: global (easier to parse the file as a whole, re-use possible)
- Yves: local (more self-contained)
- Milan: local: (Splitting file, global make that difficult)
- Christian: local

Can at least share code between source/target when possible:

  <native id='1'>xxx</native>
  <native id='2'>yyy</native>
 <source><code id='1' ref='1'/></source>
 <target><code id='1' ref='2'/></target>

- ACTION ITEM: Yves to summarize the new options in the wiki and others to add/correct afterward.

Christian noted that looking at RDFa (RDF+attribute) could give us ideas.
Look also at http://www.slideshare.net/BenjaminAdrian/rdfa1

=== 5) Any Other Business?

- Anyone going to the Localization Word in June (Barcelona)?
(for possibly a face to face)
-> nothing sure for now.

- time change now that we have no one in Australia? -> 8am? 9am?
Yves asked if we could move to 8am. All attending were OK.

- ACTION ITEM: Yves to ask the rest of the group by email.

- Next meeting will be Feb-08.

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