OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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

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

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


> 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 doesnt "modify" the content any more than adding <segment> does. And therefore if its 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.

Im afraid user requirements trumps developers 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. Well 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 didnt find much support Im 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.



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