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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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


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


Agree 100%. But hmmm. I'm trying to provide the most useful reporting I can for users of my utilities. 

The problem is error logs, including mine, are usually difficult to read and not always useful:

-------------Start Report-------------
Violations found:

Bad: <note id="n4"> , (code 2) subFS is not allowed without fs

Bad: <note id="n4"> , (code 2) subFS is not allowed without fs

Bad: <group> , (code 28) must be one of the following patterns: "*" or  "0" (where 0 means integer) or  "0,0" or "0,*"

Bad: <ctr:item> , (code 16) the value MUST be either content to signify the content of an element, or the name of the attribute relating to the revision data

. . . etc.

-------------End Report-------------

It seems a more useful way to show users where the violations are would be to just write the XLIFF file back, and inject the error reports exactly where they occur:

<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" srcLang="en" trgLang="fr" version="2.0">
<file id="f1" xmlns:xmrk="http://www.xmarker.com";>
  <skeleton/>  <!-- Bad: an empty <skeleton> must have an href attribute -->
  <unit id="1">  <!-- Bad: Blah blah -->
   <segment>
    <source>source</source>
    <target>target</target>
   </segment>
  </unit>
</file>
</xliff>

Ah, maybe if a file has a violation we just call the output an "error log," and also print the annotated XLIFF as reference:

-------------Start Report-------------
Violations found:

Bad: (#f=f1) The attribute href is REQUIRED if and only if the <skeleton> element is empty.
Bad: (#f=f1/u=1) Blah blah
. . . 

See the errors printed inline below:

<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" srcLang="en" trgLang="fr" version="2.0">
<file id="f1" xmlns:xmrk="http://www.xmarker.com";>
  <skeleton/><!-- Bad: an empty <skeleton> must have an href attribute -->
  <unit id="1"><!-- Bad: Blah blah -->
   <segment>
    <source>source</source>
    <target>target</target>
   </segment>
  </unit>
</file>
</xliff>
-------------End Report-------------

So the writer's defense is that they are not writing a non-compliant XLIFF file. Rather they are writing a very robust error report.

Maybe?

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Saturday, April 05, 2014 12:50 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] What is an agent compelled to do when it encounters a violation?

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



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 





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