Hi Yves and David,
I agree with both of you.
Cheers,
Christian
From: David Walters [mailto:waltersd@us.ibm.com]
Sent: Dienstag, 19. Juli 2011 15:45
To: Helena S Chapman
Cc: xliff@lists.oasis-open.org
Subject: RE: [xliff] Element simpleNote
Using an entire standard as a supplement to XLIFF is quite different than using a couple of elements or features from another standard. If we started using one or two elements from ITS, a couple from TBX, a couple from SRX, a couple from TMX, etc., then XLIFF would quickly become overly complex. If any of those standards changed how those items were defined, XLIFF would be impacted and possibly have to implement its own function to maintain continuity. The more self-contained XLIFF is, the more usable and flexible it can be.
David
Corporate Globalization Tool Development
EMail: waltersd@us.ibm.com
Phone: (507) 253-7278, T/L:553-7278, Fax: (507) 253-1721
CHKPII: http://w3-03.ibm.com/globalization/page/2011
TM file formats: http://w3-03.ibm.com/globalization/page/2083
TM markups: http://w3-03.ibm.com/globalization/page/2071
Helena S Chapman---07/19/2011 08:24:30 AM---"Extensions are evil if they try to implement an existing feature of XLIFF. I don't see why they wo
From: |
|
To: |
|
Date: |
|
Subject: |
|
"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