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 - Feb-08-2011 - 15:00 UTC - Summary


XLIFF Inline Markup Subcommittee Teleconference - Summary

Present: Yves, Andrew.
Regrets: Milan, Christian, Lucia


=== 1) Admin

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



=== 2) Discussion

Requirement working page:
http://wiki.oasis-open.org/xliff/OneContentModel/Requirements
Markup options working page:
http://wiki.oasis-open.org/xliff/OneContentModel/Comparison


--- 2.1) Invalid XML character representation

ACTION ITEM: Yves to research 1.1 status
Done: http://lists.oasis-open.org/archives/xliff-inline/201101/msg00003.html and thread.

Yves: It seems 1.1 may not be the good solution.
Andrew: Agree. in our case we handle them by using inline codes (for some filters).
No specific guideline from XML people (besides that an XML file is for text)
Maybe a recommendation saying those characters should be treated as inline codes would be enough.


--- 2.2) Native data representation in inline

Thread on the native data representation:
http://lists.oasis-open.org/archives/xliff-inline/201011/msg00001.html
ACTION ITEM: Yves to summarize the new options in the wiki and others to add/correct afterward.
Done: http://lists.oasis-open.org/archives/xliff-inline/201102/msg00000.html

Andrew: Maybe general principle
A self-contained TU is valuable. So maybe using the 'global' notation would be ok only if other things are already breaking the TU self-containment.
Otherwise using inside representation would be better.

ACTION ITEM: Yves to post email to lists on possible options to get feedback.

Andrew: Examples of "nasty" cases may help us.

ACTION ITEM: Andrew to post some "nasty" examples.


--- 2.3) Other codes/features

Need to start selecting some representation of each requirements, add definition text, etc.
See wiki for some of the mrk-related discussion.
http://wiki.oasis-open.org/xliff/OneContentModel/Comparison

Outcome of the discussion: It seems that making mrk into different more specialized elements would be beneficial for validation, clarity and modularity.

One note: In some areas, the progress of the SC may be dependent on the progress of the TC, for example on segmentation or TU self-containment.

ACTION ITEM: Yves to post a note on the TC list to point out the need for progress in those areas.


=== 5) Any Other Business?

- none.
- Next meeting will be March-08 at the new time (15h00 UTC)

-end




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