Re: [xliff] XLIFF Process and Agent Related Terminology Proposal

["Dr. David Filip" <David.Filip@ul.ie>]

Hi again, Yves and all,

BTW the sole purpose of the MAY PR statements accompanying/complementing the definitions is to break (allow for breaking) the basic linear structure and to allow theoretical and practical construction of combo agents, such as modifier/translation editor/review editor.

On the other hand, localization is moving towards SOA and many highly specialized user agents may contribute to the roundtrip, as opposed to monolithic combo agents of the past :-) The linear structure illustrated on the BPMN diagram is just the simplest instantiation of the (full) framework, nothing in the framework prescribes order, except for the Extract/Merge and Modify/Rollback brackets. Iteration, and cycling are NOT prevented by the framework at hand, and the most general workflow behavior is possible between the brackets. Non-roundtrip usage scenarios, such as amassing XLIFF files for MT training are neither encouraged, nor excluded.

I also explain in a note why merging and validating are thought to be distinct and that they obviously can be part of the same tool set from the common sense point of view..

I believe that this strawman should be able to develop into a conceptual framework that will be able to address Jung's or Shirley's concerns, will allow to specify sensible re-structuring (re-grouping and re-segmenting) prerogatives, and set PRs for bin elements and validation handling.

The strawman obviously encodes my preferences and I am willing to change them if they fail to get majority support in the TC, but I am convinced that the framework maps well the logical space of processing upon a (generic) roundtrip format (there is very little XLIFF specific in the conceptual framework).

Again, the ultimate goal is to make the spec usable by a "naive implementer" who does not posses the "tribal knowledge". It should serve as tooling for creating good PRs for currently underspecified or to be specified features and modules.

Cheers

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 Tue, Dec 11, 2012 at 6:07 PM, Dr. David Filip <David.Filip@ul.ie> wrote:

Thanks Yves, I have obviously submitted a strawman that I believe might make sense based on what we have in the spec and what should still get into the spec based on the now approved features (see the validator). Discussion and modification is encouraged and welcome.

It seems clear to me that we cannot sign off a spec without PRs, but the feature/module owners seem to be hesitant to provide PRs. I thought that a framework of process and agents definitions would help here.. My inspiration is the UBL spec that starts with process definitions to base its conformance statements. The agent names are just shorthand for tool performing a certain process.

I am consciously trying to avoid assuming a specific workflow, but we cannot pretend that XLIFF is not a roundtrip container. As consequence of XLIFF being a roundtrip format, the proposed process definitions are possible.

Our core definition says that achieving roundtrip after translation is essential and this governs the core. It seems to me that mandating rollback capability in modifiers is a logical consequence of saying that roundtrip is essential.

There are obviously some options here. We might decide that

EITHER

Mergers MUST be able to accept units back no matter if their segmentation/grouping etc. has changed

OR

Modifiers MUST rollback structural changes before returning stuff to mergers.

Some of the stuff that I have now pulled together to the general definitions is now scattered throughout the spec, e.g. in inline, like the Extractor/Meger same knowledge warning..

Cheers, and looking for further input for this discussion

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 Tue, Dec 11, 2012 at 5:45 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi David, all,

I read through the proposal and I think this goes a bit overboard.

I think we can define what a “user agent” (or “agent”) is (although I see it used in many specification without definition).
Extracter and Merger (or whatever _expression_ we settle on) would be useful too, but probably in very simple terms.
And, in my opinion, that’s about it.

We define a file format, where our PRs must be expressed in relation to the format and what the user agent knows about the format. We can't assume any type of processing workflow.

So, statements like "Modifier MUST be able roll back the core and bin-file structure of an XLIFF that it has previously modified" or "Validation MUST NOT be performed at the time of Merge." are going way too far.

cheers,
-yves



From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip
Sent: Tuesday, December 11, 2012 7:35 AM
To: xliff@lists.oasis-open.org
Subject: [xliff] XLIFF Process and Agent Related Terminology Proposal

Hi all, I've been working on this process and agent related terminology. The plan is to use this as definitions in the XLIFF 2.0 spec. The idea is that this should help formulate PRs for core features, modules and extensions.
Unfortunately we still do not have sufficient module related PRs, and worse we do not have the newly approved features as Docbook articles.

Please comment on the proposed definitions within this week. If I do not hear serious objections by the end of this week I will start implementing the terminology in the Docbook spec along with some other pending changes.

The proposed text is attached (as docx and pdf) AND pasted down below. The attachment contains also an illustartive BPMN diagram (png attached separately) that was socialized with the TC before. I am aware that the BPMN digram needs to be harmonized with the proposed terminology, still I prefer doing the harmonization after the proposed terminology has been discussed and stabilized.

My plan is adding PRs to the spec by the end of 2013, so that its implementations become verifiable based on conformance statements rather than based on tribal knowledge (term courtesy of Ryan King :-).

Cheers
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

[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 inclusively.
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.
Warning:
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.
PR:
Enriching MAY happen at the time of extraction.
Enricher (Agent) – an Agent that performs the Enriching process.
Note:
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.
PR:
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.
Note:
Enricher or Extractor knowledge of the native format is not assumed while Modifying.
Warning:
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.
PR:
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.
PR:
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.
PR:
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.
Note:
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.

---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org