RE: [xliff] Source read only or modifiable?

[Yves Savourel <ysavourel@enlaso.com>]

Title: RE: [xliff] Source read only or modifiable?

Hi,

> When you do segmentation, you add elements to <unit>.

> When you add <mrk> elements, you add them to <source>.

Adding a <segment> to <unit> is the same as inserting "</source></segment><segment><source>" to the initial <source> content. Just like you would insert "<mrk>".

In both cases you break the content into parts. In both cases you can strip the added tags and get back the original content of the initial <source>.

If anything, re-segmenting has a lot more impact on the unit than doing annotation (e.g. if you join two segments you may have to remove <matches> and other children of <segment> elements, update approved and other attributes, etc).

So, I still think adding <mrk> elements in content doesn’t "modify" the content any more than adding <segment> does. And therefore if it’s ok to re-segment, it stands to reason that annotations are ok too.

> To make things worse, the description of <mrk>

> in the specification draft says it could have

> multiple nesting levels. That means extra levels

> of processing to get rid of undesired markup.

I’m afraid user requirements trumps developer’s comfort.

Not allowing things like "<mrk><mrk>Some</mrk> text</mrk>" would be like saying to HTML users: You can have text in bold or italics but not both at the same time.

>> Maybe, maybe not. If the elements for inline codes have their

>> own namespace, they don't have to follow the core prescriptions.

>> We'll see what the SC come up with. It may think having all the

>> inline markup in a single namespace is simpler. I have no opinion

>> on that yet.

>

> An important thing to keep in mind: elements from a module are

> optional and disposable.

> ...

> What would a tool that only supports "core" do with inline

> elements if they are in a module?

> ...

> That's too risky and justifies having inline elements in core.

I tend to agree with you. We’ll see what the SC thinks as a group.

> As said before, that information doesn't have to be

> in a <mrk> element. It could be stored outside <source>

> so it is not *absolutely* essential to consider

> <mrk> as an inline element.

The <mrk> is needed to delimit the span of annotated content.

The idea of using offsets didn’t find much support I’m afraid.

This said, XLIFF is just an exchange format: One can use whatever representation in the internal object model. One simple mapping from markup to offset and you have an unencumbered content.

Cheers,

-yves