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


"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."

Agreed. And the premise is also, XLIFF should not try to "scope creep" all possible modules as a stand-alone standard if there are other open supplemental standards. In response to Rodolfo's note, if the interoperability issues are on the supplemental standard, it is our job to contribute to the standard owner changes required. No different than how we would expect our user community to tell us what mistakes we have made with XLIFF.




From:        Yves Savourel <ysavourel@enlaso.com>
To:        <xliff@lists.oasis-open.org>
Date:        07/19/2011 08:46 AM
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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




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