Hi Christian,
My definition in this context is:
’third party extension’ – any extension not specified or created by the XLIFF TC.
‘extension’ - any added functionality that do not exist in the XLIFF core specification or that re-implement in a different way functionality already in the XLIFF core specification.
Regards,
Fredrik Estreen
From: Lieske, Christian
[mailto:]
Sent: den 4 maj 2012 12:57
To: Estreen, Fredrik;
Subject: RE: [xliff] Proposal for ballots on: Extensibility in XLIFF 2.0
Hi Fredrik,
I would need a definition for “third party extension” in order to cast a vote.
Cheers,
Christian
From:
[mailto:] On Behalf Of Estreen, Fredrik
Sent: Freitag, 4. Mai 2012 12:17
To:
Subject: [xliff] Proposal for ballots on: Extensibility in XLIFF 2.0
Hi All,
as discussed earlier in the week I propose two ballots to decide the overall direction for third party extensibility of XLIFF 2.0. I’m looking for a second of these proposed votes.
First ballot:
Shall we allow any third party extensions in XLIFF 2.0?
* 'Yes' for extensibility by some means
* 'No' for no extensibility at all
* 'Abstain' for need of more discussion
Second ballot to be held only if the result of the first was ‘Yes’:
What general method(s) do we want to allow for third party extensions?
* 'Elements' for extensibility by elements and attributes defined in the XLIFF specification. An example of this method is the proposed <metaHolder> feature.
* 'Namespaces' for extensibility by allowing third party namespaces at defined locations in the XLIFF documents. As we do in XLIFF 1.2 possibly with additional requirements for conformance and processing expectations.
* 'Elements and Namespaces’ to use both of the above methods to facilitate extensibility.
* 'Abstain' for need of more discussion
Once we have decided if and how we want extensibility we can proceed to work out the technical details.
Regards,
Fredrik Estreen
