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] Element simpleNote


> The use of third party extensions in XLIFF 1.2
> is a major cause of interoperability issues.

I would qualify this a bit more:

Using extensions to provide missing v1.2 features or badly-designed existing v1.2 features is an v1.2 problem not an extension problem.

Extensions are evil if they try to implement an existing feature of XLIFF. I don't see why they would be banned if they implement something that supplement the existing features.

Also, it's not because an element or an attribute belongs to a different namespace (e.g. ITS) that it is an "extension". We already do use several namespaces in the current XLIFF 2.0 core: xml:lang and xml:space for example. It may be a special case (we don't have to declare the extra namespace), but it's still something similar.

But I think we don't want to go all the other way either and allow any ITS elements indiscriminately. Maybe some features make sense to be defined using ITS, while other should be in the XLIFF namespace.

For example: I don't think our translate='no' could be replaced by its:translate='no', because the scope is different (ours implies <target>, ITS' means all children).

The bottom line is that we should allow only one 'proper' way to implement each feature.

-ys



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