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: 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


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

 

www.supratext.com

 





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