RE: [xliff] What is an agent compelled to do when it encounters a violation?

[Yves Savourel <ysavourel@enlaso.com>]

Hi Bryan, all,

> ... I suppose we might say the agent became non-compliant 
> at step (3).

Yes, an agent becomes non-compliant--for sure--when it generates the non-compliant output: clause 2.a: "XLIFF Writers MUST create
conformant XLIFF Documents to be considered XLIFF compliant."
It doesn't matter if the invalid construct is coming from the original document it read or from some markup it added.


> But given the output file that flags the violation, is the output 
> non-compliant?

Sure, it's still non-compliant. Saying something is wrong doesn't make it right :)
The comments are just useful for debugging. They mean nothing in XLIFF.


> Or to make the use case even sillier, what if the application's purpose 
> is to decorate XLIFF files with comments that identify every place 
> in an XLIFF file that there is a violation of a constraint or 
> processing requirement? Is such an application, or its output 
> doomed to be non-compliant?

Yes, the document is non-compliant and the tool is a non-compliant writer agent.
And it's ok. It's just the nature of that specific tool.
Note that the tool can still be a compliant reader.


> I suppose what I'm asking in the end, where do we 
> say *how* an agent must react to a violation?

I don't think we say anywhere what a reader should do when it finds an error.

If it can automatically fix the issue and generate a valid document, that's nice. But in most case I would expect the tool to either
just reject the document, or provide some graceful fallback and a clear warning to the user that the input document is invalid.
Note that the graceful fallback would have to generate a valid document, which may be difficult since the fallback may have removed
constructs that should be in the output.

I'm vaguely sensing the ugly second head of the Postel Law creeping out of its cave: "be liberal in what you accepts". In my
opinion, in the context of XLIFF, following that principle is not robustness, it's the path to never-interoperability-land. Tools
should at a very minimum scream very loudly when they read invalid XLIFF documents.

And this is also why providing solid validation tools for the core and the modules is also important: I don't think we can expect
that all agents will perform full validation on their own, but if they can call something that provides the service then it helps
them a lot.

Cheers,
-yves