[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] Call for Dissent was Re: [xliff] csprd01 comments 11 and 41
Hi David, Yves,
I fully agree with Yves’ statement:
“I think we have to go back to the original intent of this couple of attributes, which was how to indicate that a segment is at a stage where it doesn’t need any work anymore (and what tools do with that information is up to them).”
However, I do think approved has merit as an optional attribute. Although perhaps it only has meaning with state=reviewed to indicate whether the review is approved and the translation can be used, or not approved and must be retranslated.
Ryan
From: Yves Savourel [mailto:ysavourel@enlaso.com]
Sent: Friday, August 9, 2013 5:59 AM
To: 'Dr. David Filip'; Ryan King
Cc: xliff@lists.oasis-open.org; 'Tom Comerford'
Subject: RE: [xliff] Call for Dissent was Re: [xliff] csprd01 comments 11 and 41
Hi David, Ryan,
I’m also confused with approved and state.
The definition of approved (as of the 6 aug editor’s draft) says “Approved - Indicates whether the holding <segment> element contains a translation suitable to be used when converting the XLIFF file to original format.”
One could very well want to merge a file with not final translation. So the definition of approved itself is strange.
We also have a PR for <unit> that says: “A <unit> element is considered to be translated when all its <segment> children with translate attribute not set to no have the approved attribute set to yes.”
What ‘translated’ means here? Is it done? Is it ready for edit?, etc. In addition the PR itself is not associated with any explicit action. What a tool is suppose to do if all segments are approved or not?
I think we have to go back to the original intent of this couple of attributes, which was how to indicate that a segment is at a stage where it doesn’t need any work anymore (and what tools do with that information is up to them).
I believe that state provides such information and we could remove any confusion by just removing ‘approved’.
Cheers,
-ys
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip
Sent: Friday, August 9, 2013 1:47 PM
To: Ryan King
Cc: Dr. David Filip; xliff@lists.oasis-open.org; Tom Comerford
Subject: Re: [xliff] Call for Dissent was Re: [xliff] csprd01 comments 11 and 41
Ryan, there seems to be a misunderstanding
In the current solution (as described in the CFD), The approved flag is required, state and substate are otpional. state becomes necessary only if you want to use a private substate machine.
Because state has 4 values and is optional, it would be too tricky to use to define a macro state of a unit, group, etc.
The merit of the four values is just to provide some basic interoperability for more complicated state machines hidden in substate, that is why it is enforced with substate.
approved is a simple flag that CAN [this is intentionally not normative, just a suggestion to implementers, as we do not want to bake processing logic into the spec] be used as a readiness signal
If we make it recursively inherited it will be even simpler to use as the readiness signal in the sense described in the macro state definition..
Do you want to propose a specific change text/solution. I do not think that just deleting it would be satisfactory..
I thought that using <firstterm>Translated</firstterm> was a good solution, becaus it does not really prescribe an implementation behavior.
Maybe it could be moved from the processing required to the front matter definition..
Please let me know during today if possible
Rgds
dF
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 Fri, Aug 9, 2013 at 5:14 AM, Ryan King <ryanki@microsoft.com> wrote:
Thanks David for the explanations. I agree with state being required, but I would personally not make approved required and I would remove the processing requirement using translate=yes and review=yes as a "macro translated state". That is just too prescriptive, especially when just state=translated can serve this purpose and even more so if we make it inheritable from higher up in the tree structure.
My 2 cents,
Ryan
Sent from my Windows Phone
From: Dr. David Filip
Sent: 8/8/2013 6:34 PM
To: Ryan King
Cc: Dr. David Filip; xliff@lists.oasis-open.org; Tom Comerford
Subject: Re: [xliff] Call for Dissent was Re: [xliff] csprd01 comments 11 and 41Thanks, Ryan
let me explain below
On Fri, Aug 9, 2013 at 1:19 AM, Ryan King <ryanki@microsoft.com> wrote:
Hi David, All,
In principle, I agree with the PR that initial is inconsistent with approved=yes and final with approved=no. However, I think that there is some overlap in meaning between reviewed and approved=yes compared to final and approved=yes. In other words, I think reviewed and approved=yes can be enough to flag that the segment is “ready to be used”.
Sure there is an overlap
Since approved is just a simple flag and easy to maintain, we made it required. And approved yes is intended as always sufficient readinness signal
Maybe this still needs to get more explicit in the spec.
At the same time we did not want to bake to much process logic into the spec, as you warned us not to..
So people who will want to benefit from all four states eventually introduce substates for even finer process granularity will probably not use approved=yes earlier than on state=final
I still don’t think this PR on <unit> is appropriate…
2.2.2.5.
•A <unit> element is considered to be translated when all its <segment> children with translate attribute not set to no have the approved attribute set to yes.
…state=translated approval=no and state=translated approval=yes both indicate my <unit> is translated, the former just isn’t approved.
This is a very old (long stable) part of the spec and I don't think it should be changed. This is using translated as a macro state as per one of the initial definitions. It is actually NOT about the value of the state attribute that is even not defined on unit.
This is also a reason to make the flag required and vice versa, the state cannot be used to define this macro-state because it is optional.
Thanks,
Ryan
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip
Sent: Tuesday, August 6, 2013 12:18 PM
To: xliff@lists.oasis-open.org
Cc: Tom Comerford
Subject: [xliff] Call for Dissent was Re: [xliff] csprd01 comments 11 and 41
Hello, everyone,
since this solution as implemented in the current working draft, has received support and incited no dissent in today's informal meeting, I am making an official mailing list call for dissent.
Unless someone proposes another solution by Thursday, August 10 PDT COB, I will consider comments 011 and 041 resolved by my proposed and implemented edits.
Best regards
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 Sun, Aug 4, 2013 at 8:00 PM, Dr. David Filip <David.Filip@ul.ie> wrote:
Thanks Tom, for exposing the possible combinatorics.
Unfortunately, there was no discussion on this during the last month.
I am going to implement in the spec the following and we will need to discuss if the solution is satisfactory in the TC meeting.
Please discuss this in this thread prior to the meeting, if you do not like the proposed solution.
The changes I am implementing are the following:
1. Making the state attribute (flag) obligatory.
2. Adding PRs that make initial inconsistent with approved=yes and final with approved=no. In all other cases the required flag has the priority.
3. I am also adding a PR as per the generalized sub-attribute behavior, i.e. the obligation to update or delete the sub if you are changing the state.
Background thinking
My thinking is that the role of the attributes is distinct and since @approved has been used to define the macro state translated of a unit consisting of approved segments, I assume that the flag has priority and should be required rather than optional.
Use of state is optional, yet necessary for those who need finer granularity and the prerequisite for using an even finer grained private state machine.
Finally, the general sub attribute PR debate seemed to support the generalized approach I am using for the substate PRs here.
Thanks for your attention
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, Jul 2, 2013 at 2:29 PM, Tom Comerford <tom@supratext.com> wrote:
Hi all,
This is in regard to csprd01 comments 11 and 41, concerning the possible conflict between values of the state and approved attributes for the segment element.
A segment may have state="initial", in which case we should expect approved="no". Similarly, if approved="yes" it implies that the state must be "translated" and "reviewed"; else approval is not possible. A segment that has state="final" should never have approved="no". This situation is ambiguous and leaves it to implementers and ultimately to processing agents to interpret conflicting values; i.e. by giving priority to one or the other of the attributes.
Here's how I interpret these conditions; please let me know if you disagree. First, if a segment state="translated" then it's subject to review, so cannot yet have been approved. If the segment state="final" then it must have been approved. What remains unclear in my mind is the intent of state="reviewed": does this imply approved="yes"? If so, then the approved attribute correlates directly with a specific value of the state attribute and is superfluous. On the other hand, if we can have state="reviewed" and it can be either approved or not approved, then we need processing requirements to resolve the ambiguity.
There are several possible ways to resolve the conflict between these two attributes:
1. add a processing requirement to prohibit inconsistent combinations of the state and approved attributes
2. add a processing requirement that the approved attribute applies if and only if state="reviewed"
3. expand the list of values for the state attribute to clarify the distinction between reviewed/unapproved and reviewed/approved, and drop the approved attribute
4. clarify the meaning(s) in the values of the state attribute, and drop the approved attribute
Of these, I think (3) and (4) are less likely to result in ambiguity, though any of them will clarify to implementers the intent of these attribute values. Comments, clarifications and critiques welcome.
Thanks,
Tom
Tom Comerford
tom@supratext.com+1 856 787 9090
Supratext LLC
43 Michaelson Drive
Mount Laurel, NJ 08054
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]