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
