[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
FWIW, yesterday I added processing requirements to the definition of <skeleton> stating that it must be kept unchanged. Regards, Rodolfo -- From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip All, Rodolfo, Yves, I agree that the target related PR belongs there and not to the general PRs. I obviously have an issue with not protecting modules as a general rule, that will of course have exceptions when removing core elements according to core processing requirements. Module data are not essential in the same way as core, but unlike extensions they are the essential and only possible way how to cover their specific functionality. So they must have as a general rule a higher level of protection. Otherwise there is no substantial difference between module and extension. In normative theory, special rules always beat general rules. And maybe we have so many special rules that there is little value left in setting out general processing requirements, as all implementers must obviously follow the core PRs and all implementers of modules must follow the module's PRs. Still, in the general section we must at least say what to do with modules that you do not support and what to do with extensions that you do not support in case when it does not follow from core manipulations. The general principle of course is when a core element is gone and there is no clear successor the dependent module or custom data not only must not be preserved but simply cannot be preserved as there is no carrier left. There is no harm in saying.. > - All user agents MUST follow the processing requirements associated with This has the fundamental issue of not protecting modules better than extensions: So I counter propose to have the following two paragraphs instead: - A user agent that does not support a given module element or attribute MUST preserve it, except when a core processing requirement specifies otherwise. (See, for example, section 2.8.3 Segmentation Modification). - A user agent that does not support a given custom namespace element or attribute SHOULD preserve it, except when a core processing requirement specifies otherwise. (See, for example, section 2.8.3 Segmentation Modification, or 2.2.2.3 skeleton). This general rule should be overriden with a specific rule in the section 2.2.2.3 skeleton - Because skeleton - if present - is essential for merging back of translatable content, skeleton including its custom elements MUST be preserved. We will also need a definition of "support" in section 1.1.2 Definitions if we go with this wording. It should say that to support an element or attribute means to read, understand, process, and write it according to its processing requirements. Best regards 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 On Mon, Nov 5, 2012 at 6:42 PM, Rodolfo M. Raya <rmraya@maxprograms.com> wrote: > -----Original Message----- > Of Yves Savourel > Subject: RE: [xliff] XLIFF 2.0 spec - dF Issue #01 - Extensibility and processing Hi,
XLIFF-defined should be read as "defined by the XLIFF TC". The ITS group can propose an enhancement but cannot define an XLIFF module, it has to be defined (probably based on an ITS proposal) and approved by the XLIFF TC. Any module will have to use a namespace defined by the XLIFF TC following the rules stated by OASIS.
Sure, it should be moved.
Nice proposal.
Nice wording as well, works for me.
--------------------------------------------------------------------- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]