[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Extensibility methods
Hi Yves, Rodolfo, I would say that the rule for <segment> and <ignorable> should be that if the segment is merged or split an application: * MUST remove any non-core elements and attributes it does not support. * MAY remove any non-core elements and attributes. from the affected <segment> and <ignorable> elements. This probably hold for other places as well. It allows an application to preserve as much data as it can and if it cannot determine if it is safe
it must remove the data. Since it is optional data that should not be an issue. I think we should decide on this type of expectation whenever a module add constructs on top of core and define the expectation in core. Regards, Fredrik Estreen From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Rodolfo M. Raya Hi Yves, FWIW, <matches> currently lives in the core, not in a module. It cannot be in a module because it depends on core elements, like <source>, <target> and inline
elements. It could be moved to a module if we define elements that duplicate the functionality of <source>, <target> and all inline codes. Notice, however, that <matches> is an optional element and is not required when the XLIFF file is created; it can be
added (or not) after creating the XLIFF document. The only module we have defined so far is the one that handles glossaries. Data from an XLIFF module is optional. A "module" is defined as something not required to create an XLIFF file, translate it and generate a translated document.
A tool that doesn't know how to use optional module data can safely ignore it and doesn't have to maintain it. Such tool may even delete module data, as it is not required for generating a translated document. If you enhance an XLIFF file by adding <glossary> elements, the user can take advantage of that data by using a tool that supports it. If the user prefers to
work with a tool that cannot handle <glossary>, that doesn't interfere with the translation process and the generation of a translated document. The tool may safely delete <glossary> elements and nothing will be damaged.
Things that must be preserved by all tools should be part of the XLIFF core and have precise processing expectations. Even optional core elements, like <matches>,
should have processing expectations that indicate whether they can be removed or not. Anything not specified in the XLIFF core is by definition not essential for completing the translation cycle. In other words, disposable. Regards, Rodolfo --
--------------------------------------------------------------------- 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]