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] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing requirements



Hi,
 
I would prefer to protect elements from official XLIFF modules and not from custom extensions if they are present at <segment> level.  
 
Regards,
Rodolfo
--
Rodolfo M. Raya
Maxprograms http://www.maxprograms.com
 
 
-------- Original Message --------
Subject: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and
processing requirements
From: "Dr. David Filip" <David.Filip@ul.ie>
Date: Thu, October 25, 2012 11:36 am
To: xliff@lists.oasis-open.org

Dear Yves, all,

Yves proposed some time ago the general processing requirements for
extensibility.

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
overlap].

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
dF

Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
mailto: david.filip@ul.ie


David Filip, Ph.D.
=====================
cellphone: +353-86-0222-158
mailto:davidf@davidf.org
Please use david.filip@ul.ie for LRC business
www.davidf.org, http://www.linkedin.com/in/davidfatdavidf

---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org



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