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 - May-10-2011 - Summary

XLIFF Inline Markup Subcommittee Teleconference - Summary

=== 1) Admin

Minutes of previous meeting:

Present: Yves, Christian, Andrew.

=== 2) Discussion

Requirement working page:

Markup options working page:

--- 2.1) Native data representation in inline

Thread on the native data representation:

ACTION ITEM: Andrew to post some "nasty" examples on inline codes.
Done see: http://lists.oasis-open.org/archives/xliff-inline/201105/msg00004.html

- How to link ending with starting codes when they are isolated?
(id, rid?) should we have id on the ending code?

<start id='1'/> <end id='2' rid='1'/>

Christian:  We recently got the comment that we should consider that ids should always be unique.
Yves: Concern about need for rid-type attribute or not. Experience says it wasn't used much in 1.2.
Christian: Comment is viewpoint of DTD world. xml:id is different maybe?

ACTION ITEM: Christian to read up on ID and report.

- Storage: Three types:
a) no storage
b) in element (not in attribute)
c) outside (in TU not at file-level) then IDs are involved as well for referencing the data.

Are the notations interchangeable?
We may need to not overload the identity-id with the reference to the storage.

--- 2.2) Cloning, deletion, addition of inline codes.

Current requirements list need of feature to clone and add inline codes.
See email here: http://lists.oasis-open.org/archives/xliff-inline/201104/msg00000.html
And http://lists.oasis-open.org/archives/xliff-inline/201104/msg00004.html discussion

- canDelete
- canReplicate
- canReorder
- canMoveOutOfParent

Permission to change attributes?
-> poor practices
Andrew: Those are more like hints for file-type agnostic editing.

Added codes:
-Do we need to identify codes that are new?
Andrew: not sure if it adds value.
Would have to rely on editing tool.
Andrew: Assume same tool will re-create output, using different is probably not doable.

Christian: described a scenario:
translator working in html-like or xml (e.g. flash)
someone modifies the native markup (e.g. add code)
another tool may not 'understand' that new code, but for some file format we can do more (e.g. HTML)

Andrew: Right but we need to be careful with what we can do with some file-types and not others.
(e.g. not working for DOCX)
The parser can annotate the file with that info.
e.g. table that carry the mapping type->native data

Andrew: If we concider those as hints rather than permissions, then other things may be to consider (in addition to requirements):
For example: should a give code be excluded/included in a segment (e.g. bookmark)

Christian : +1 for separation of concerns

--- 2.3) Span/markers -type elements

XLIFF 2.0 needs specific elements rather than a generic <mrk>.
See http://lists.oasis-open.org/archives/xliff-inline/201104/msg00004.html discussion

ACTION ITEM: Christian to provide background info on semantic web. Possibly examples.

Also how to mark overlapping spans: 

Choices: <span></span> or <startSpan/>/<endSpan/>

Andrew: prefer A) (real xml). The combining may not be needed (e.g. 1 or 2 'notrans' gives the same functionality anyway)
Yves: but 'term' you would have to re-construct
Andrew: yes -> so need for precedence

Christian: Possibly a different notation altogether:
A general container, with attribute per type of information
And use several info per span.

ACTION ITEM: Christian to post an email about this possible different implementation.

Other metadata?

- all of ITS data categories? http://www.w3.org/TR/its/ (e.g. ruby)
- maybe also look at the extra features in ITS (http://www.w3.org/International/its/wiki/IssuesAndProposedFeatures)

Yves: what about White space preservation or not?
Do we need that option inside the content?

Andrew: Filters should take care of handling this up-front.
Default should preserve the WS.

=== 3) Any Other Business?

Christian: We may want to discuss segmentation relationship with inline codes.
Yves: we have a requirement: "Inline codes should have a way to store information about the effect on the segmentation"

Next meeting will be Jun-14 at 14h00 UTC


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