xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [xliff] Element simpleNote
- From: Helena S Chapman <hchapman@us.ibm.com>
- To: xliff@lists.oasis-open.org
- Date: Tue, 19 Jul 2011 09:17:13 -0400
"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]