OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

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

Subject: Re: [xliff-comment] XLIFF 2.0 csprd01 comment by David Filip - classification of processes and agents to improve precision of conformance statements

Hi David and TC Members,

Since I am not quite sure if it is appropriate to comment on ongoing TC discussions at this stage, which might be beyond the public reviewing phase of the XLIFF 2.0 draft specification, I would like to add my doubts to this attempt of defining a certain terminology to the specification.

The proposed terminology adds a very specific process-oriented view to the specification which might find a better place in the description of an accompanying best/good practice document. My points are:

(1) Definition of "XLIFF payload." This might be related to viewing XLIFF as a container format with all the features that might be associated with the container metaphor, and therefore should only be part of the general rational behind XLIFF 2.0 (see my previous comments in the public review phase).

(2) The introduced agents -- extractor, merger, enricher, modifier, source editor, translation editor (or better target editor), revision agent, validator -- are defined with a very particular processing purpose and XLIFF lifecyle in mind. It is not appropriate to force the em- and deployment of XLIFF in any (usage or processing) direction, and so these agents and their asscoaited tasks might participate in a variety of possible XLIFF workflows that should be described as one or several possible application scenario(s) only.

(3) Since the described "tasks" might also find their location within the Resource Data Module -- sort of external processing guideance with additional references to, for example, change tracking and validation information -- is is not appropriate to define this terminology as "normative."

(4) There are certainly other agents and tasks we can think of, for example, just extend the introduced "translation editor" to a full fledged (automated) translation agent.

Thanks and all the best,


On May 28, 2013 at 18:49 (CEST), Dr. David Filip wrote:
Fellow TC members,

our specification is still too document centric. Compared to XLIFF 1.2,
we have many Processing Requirements and it is very well so.
However the only explicit statement we are making towards the
application conformance target is isolated and does not have much
backing throughout the spec (see evaluation by TAB member Martin Chapman
in last TC minutes)

I attach and include in the e-mail body proposed definitions that should
be included in the spec and used throughout PRs to refine the intended
application conformance targets.

It is vital that the spec contains normative language that will allow
for unambiguous construction of application conformance profiles and to
specify admissible document states before and after a specific processes
are performed by agents of specific types.
This proposal will be presented on the 4th XLIFF Symposium, it should
also be preliminary discussed in the F2F on June 10, 2013

[DRAFT] [Normative]

Process and Agent Related terminology in XLIFF 2.0

Agent – a tool that does anything to an XLIFF file from extract to merge

Extract/Extraction – the process of encoding localizable content from a
native content or User Interface format as XLIFF payload, so that
localizable parts of content in the source language are available for
translation into the target language along with necessary context.

Extractor (Agent) – an Agent that performs the Extraction process.

Merge – the process of importing XLIFF payload back to the originating
native format, based on the full knowledge of the extraction mechanism,
so that the localized content or User Interface strings replace the
source language in the native format.

Merger (Agent) –an Agent that performs the Merge process.


Unless specified otherwise, Merger is deemed to have the same knowledge
of the native format as the Extractor throughout the specification.
Mergers independent of Extractors can succeed, but it is out of scope of
this specification to specify interoperability for merging back without
the full extractor knowledge of the native format.

Enrich/Enriching – the process of associating module and extension based
metadata and resources with the extracted XLIFF payload.


Enriching MAY happen at the time of extraction.

Enricher (Agent) – an Agent that performs the Enriching process.


Extractor knowledge of the native format is not assumed while Enriching.

Modify/Modification – the process of changing core XLIFF structural
elements and bin-file module elements.

Modifier (Agent) – an Agent that performs the Modification process.


Structural elements MAY be Modified and Enriched at the same time.
Modifier MUST be able roll back the core and bin-file structure of an
XLIFF that it has previously modified.


Enricher or Extractor knowledge of the native format is not assumed
while Modifying.


Rollback of Modifications performed by a different Modifier is out of scope.

Edit Source/Source Editing – the process of changing payload of <source>
children of <segment> elemensts.

Source Editor (Agent) – an Agent that performs Source Editing.


Source editing MAY be performed at the time of Modification.

Translate/Translation - a rendering of the meaning of source text,
expressed in the target language. As an XLIFF based process it means
creating and changing <target> children of <segment> elements.

Translation Editor (Agent) – an Agent that performs the Translation process.

Review/Revision – the process of creating or changing any annotation
elements, attributes or values specified in core, modules or extensions.
This includes marking spans of <source> and <target> children of
<segment> elements.

Revision Agent – an Agent that performs the Revision process.


Revision MAY be performed at the time of Translation.

Revision MAY be performed at the time of Modification.

Validate/Validation – the process of checking XLIFF payload against any
rules specified via the Validation Module or any general, core or module
specific Processing Requirements.

Validator (Agent) – an Agent that performs the Validation process.


Validators MAY add test results via the Validation Module.

Validator MUST not modify any other XLIFF elements, attributes or values.

Validation MUST NOT be performed at the time of Merge.


Extractor/Merger Agents will benefit from use of a Validator. Even
though the Validator will often be a part of the same tool/platform, it
is important to distinguish between validation and the actual Merge.
Validation will routinely precede Merge, while failed Validation will
lead to exception handling, such as returning the XLIFF file to a
Revision Agent or Translation Editor, Modifier etc.

Dr. David Filip
University of Limerick, Ireland
telephone: +353-6120-2781
*cellphone: +353-86-0222-158*
facsimile: +353-6120-2734
mailto: david.filip@ul.ie <mailto:david.filip@ul.ie>

*Prof. Dr. Jörg Schütz* *|* bioloom group *|* Bahnhofstr. 12 *|* D-66424 Homburg *|* Fon +49-6841-756-338 *|* Mobile +49-170-801-9982 *|* joerg.schuetz@bioloom.de

*bioloom group* *|* Vertreten durch / Represented by: Prof. Dr. Jörg Schütz *|* Sitz / Register: Homburg *|* USt-IdNr. / Tax-Id.: DE261087278 *|* Web: www.bioloom.de

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