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] Teleconference - Jun-08-2010 - 13:30 UTC - Summay


XLIFF Inline Markup Subcommittee Teleconference - Summary

=== 1) Admin

Attendees:
Yves, Arle, Milan, Asgeir, Andrew.


--- Minutes of previous meeting:
http://lists.oasis-open.org/archives/xliff-inline/201005/msg00006.html

Asgeir: Move to accept minutes.
Milan: second.
No dissent.


--- Welcome to Arle who is joining the SC to represent OSCAR.

Yves: Arle, from LISA is joining the SC, thanks and welcome.
Arle: LISA will spend more time in standards. So will try to be active.


=== 2) Scope 

See http://lists.oasis-open.org/archives/xliff-inline/201005/msg00010.html
http://wiki.oasis-open.org/xliff/OneContentModel

Yves: See the 'final' page for text.
Asgeir: I re-worded some sentences to make them flow better. Please check and make sure it's fine.
Yves: Let's spend 2mn reading since we have them there.
...2mm of silent reading...
Yves: Looks fine to me. Comments anyone?
None.
If anything comes up later use the mailing list. 


=== 3) Requirements

Everyone had the action item to: "start looking at the requirements and add as needed".
http://wiki.oasis-open.org/xliff/OneContentModel/Requirements

Going through the requirements from top to bottom.
Asgeir is editing the page, Yves refreshing it.


--- 1.1 Should be able to represent standalone codes

TODO: add an example to avoid possible confusion with possible other line-break requirements.
Looks fine otherwise.


--- 1.2 Should be able to represent balanced paired-codes

Looks fine to all.


--- 1.3 Should be able to represent paired codes that have been separated

Discussion and addition of the note: The format must support marking of pairs across segment boundaries.
Discussion on Should/must: replace Should by Must in non-optional requirements. Done.
Looks fine to all after changes.


--- 1.4 Must be able to represent paired codes that are overlapping each other

Yves: made-up example maybe not great. Will try to get a real one.
Arle: Checking InDesign... no luck.

ACTION ITEM: Yves to fine a real example for 1.4

Discussion on definition of inline code. Should be added to the term list in the main wiki page.

Example of proposal: "A non-textual data structure within the translatable content."

ACTION ITEM: Asgeir to start an email thread on this definition.


--- 1.5 Should be able to mark up spans of content and associate them with standardized information
And 1.6 Should be able to mark up spans of content and associate them with user-defined information

Discussion on namespace vs specific markup:

- Text <ns:mrk>text</ns:mrk>
- Text <mrk ns:attr>text</mrk>
- Text <mrk type=''>text</mrk>

Must be able to mark up spans of content in addition to original codes
Must be able to associate data/information with spans of content

Yves: Reaching the end of the hour: let's continue that discussion by email.


=== 4) Any Other Business?

ACTION ITEM: Arle to bring any additional requirement from OSCAR.

-end





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