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: The mrk element


Hi everyone,

Two questions on the topic of the mrk element:


=== 1) type='generic':

As I was trying to get something stable for <mrk> I realized that we left the question about <mrk translate='yes'> half unanswered (we got side tracked in talking about schema flexibility).

It seems that if we use type='generic' we should make translate mandatory in this case, and forbid the other attributes. That would eliminate un-desirable cases.

So to summarize, is the following looking fine?


A) If type='generic' (default value for type)
- translate is required
- value is forbidden (because unused)
- ref is forbidden (because unused)
- id is optional


B) If type='term'
- translate is allowed (if not present its value is the same as the parent)
- value is forbidden (because unused)
- ref is an optional pointer to additional information (what format this additional information is in?)
- id is optional

Example: <mrk translate='no'>text with <mrk type='term'>TERM</mrk></mrk>


C) If type='comment'
- translate is allowed (if not present its value is the same as the parent)
- value is required if ref is not set and contains the text of the comment
- ref is required if value is not set and points to an external comment (what format this comment structure has?)
- id is optional


D) If type='<something-else>'
- translate is allowed (if not present its value is the same as the parent)
- value and ref and id have a behavior defined by the user-defined annotation


=== 2) multi-spans annotations:

We touched on the cases where we would have a single <mrk> split into two by a segment break for example. We said we would keep them as two separate mrk (vs introducing some <sa>/<ea> element) and allow for joining them when the split is removed.

This led to the question of an extra attribute to indicate that two adjacent <mrk> should not be re-joined.

I think it might be easier to use the id attribute: same id means the mrk elements are re-joinable:

Before:

<segment><source>Some <mrk translate='no'>text: stuff</mrk></source></segment>

After the split:

<segment><source>Some <mrk id='1' translate='no'>text: </mrk></source></segment>
<segment><source><mrk id='1' translate='no'>stuff</mrk></source></segment>

Note that if the split include ignorable we are for some funky markup:

<segment><source>Some <mrk id='1' translate='no'>text:</mrk></source></segment>
<ignorable><source><mrk id='1' translate='no'> </mrk></source></ignorable>
<segment><source><mrk id='1' translate='no'>stuff</mrk></source></segment>

Any thought?
-yves




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