Re: [xliff] Call for Dissent was Re: [xliff] csprd01 comments 11 and 41

Subject: Re: [xliff] Call for Dissent was Re: [xliff] csprd01 comments 11 and 41

Thanks Yves, I just started explaining why approved with these constraints is not redundant, when I noticed your follow up.

I said in a previous e-mail that state of segments and readiness for merging are a different thing because of relatively new use cases such as crowdsourcing and raw machine translation publishing.. And this is my bottom line.

It is not true that there is no relationship between state and approved in the current solution

But the relationship is minimized to cater for a variety of use cases.

Approved=yes is consistent with all states except for initial

We suggest that approved is a merging readiness hint, but it is up to the Merger to decide if they wait for state=final, or if they are happy with state=translate for interim publishing of support content or crowdsourced version of a wiki article etc.

I do not think that this sort of freedom is bad, in fact this is exactly what I intended with the proposed solution.

If the relationship is maximized, than of course one of them becomes redundant (and we would need to kill the less expressive not to kill substate), but do we really want that? It would not cater for important use cases, in fact it would just work for the traditional one stop scenario.

I thought that everyone agreed that we do not want prescribe too much processing logic, just set the playground.

I agree that the default is not needed for a required attribute, I just mechanically changed optional to required as part of the proposed solution.

However, if the TC agrees that we keep approved (that it is something else than state and it is important to cater for important use cases, I would make it optional on segment again, with the defaults inherited recursively (as suggested by Ryan), and on file the default would be obviously "no".

I just have not implemented the inheritance yet, since I do not want to do it in vain in case approved is indeed killed..

Cheers

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 Sun, Aug 11, 2013 at 6:52 AM, Yves Savourel <ysavourel@enlaso.com> wrote:

> Then we have the Constraints in state:
> [[
> - The optional attribute state MUST NOT be set to final if
> and only if the required attribute approved on the same
> <segment> element
> is set to no.
> - The optional attribute state MUST NOT be set to initial
> if and only if the required attribute approved on the
> same <segment> element is set to yes.
> ]]
>

> d) The second constraint is (hopefully) incorrect: we can't
> have state='final' also when approved='yes'? so we can never have
> state='final'? Obviously you meant "MUST" instead of "MUST NOT" here.

Obviously I was not completely awake when I read the second constraint.
It's not incorrect, and therefore we can't infer the approved value when state is neither initial or final.

But the bottom line remain the same, perhaps even worst: there is no clear relation between when a segment is ready to be merged and
its state. And the tools do whatever they want anyway.

So I would say that while the approved information is not always redundant, it's not interoperable and rather useless to the XLIFF
processors. If the tool wants to base the merging on information about the status of the translation they should look at state.

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

xliff message