[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Proposal for ballots on: Extensibility in XLIFF 2.0
|
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:christian.lieske@sap.com] Hi Fredrik, I would need a definition for “third party extension” in order to cast a vote. Cheers, Christian From:
xliff@lists.oasis-open.org
[mailto:xliff@lists.oasis-open.org] On Behalf Of Estreen, Fredrik 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]