[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing requirements
-------- Original Message --------
Subject: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and
From: "Dr. David Filip" <David.Filip@ul.ie>
Date: Thu, October 25, 2012 11:36 am
Dear Yves, all,
Yves proposed some time ago the general processing requirements for
As result, in the current spec, as part of the currently used
processing requirements, we forbid deletion of extensions.
If we insist on forbidding to delete extensions, we effectively
undermine the other normative statement that we make, i.e. that tools
must not rely on custom extensions for merging back.
IMHO the general processing requirements should only protect modules
[obviously including the mda module], but not extensions.
It seems odd to enforce preservation of 3rd party extensions. If
someone wants to effectively use extensions for broader
interoperability as opposed to internal processing aid [which is fully
OK], they should seek to warrant their survival with other means than
a "carte blanche" from XLIFF TC.
For instance, preserving ITS based extensions should be warranted by
the W3C recommendation (and its implementers) rather than the OASIS
stanadard and its implementers [the implmeneter groups can obviously
Anyway, all extension owners, including W3C WGs and similar can seek
to promote their extensions as XLIFF modules, as long as these do not
compete with core or other modules features [general principle].
Other method can be simply contractually agree on usage of extensions
within a supply chain or similar..
Promoting (to be) widely used extensions as modules would have merits
1) Better protection of features should be an incentive for proposing
commonly applied modules rther than rely on private extensions
2) Extension will be vetted for hidden conflicts if submitted as
module proposals for the TC, which should prevent the laissez fair
situation we have with 1.2 extensibility..
3) Growing usage of modules as oppesed to random extensions will
gradually broaden the public interoperability area [thanks to the
general non-compete principle].
Thanks for your attention
Dr. David Filip
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
David Filip, Ph.D.
Please use email@example.com for LRC business
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com