Re: [ACTION-320]: Localization Quality Précis Retain in Spec.

Felix

Apologies for the lack of thoroughness. You are right. In line with the 
other categories locQualityRatingScorePointer, 
locQualityRatingVotePointer, locQualityRatingThresholdPointer and 
locQualityRatingProfileRefPointer can all be dropped and Global markup 
along with them.

I would like to retain the four non-Pointer attributes for local markup 
(locQualityRatingScore, locQualityRatingVote, locQualityRatingThreshold 
and locQualityRatingProfileRef) and I don't think there's any contentious 
issues with these.

Jirka, sorry for any inconvenience.

Phil.





From:   Felix Sasaki <fsasaki@w3.org>
To:     public-multilingualweb-lt@w3.org, philr@vistatec.ie, 
Date:   28/11/2012 10:41
Subject:        Re: [ACTION-320]: Localization Quality Précis Retain in 
Spec.



Am 28.11.12 10:54, schrieb Phil Ritchie:
All 

Arle and I spoke this morning. 

VistaTEC definitely sees a requirement for Localisation Quality Précis - 
that is, a data category to contain document level, quality related 
metadata. The locQualityIssue metadata has much more meaning when it is 
referenced back to an overall score and pass/fail threshold and optionally 
point to other non-normative information (contained in the rating). 

There is a current proposal for a change of name to "Localization Quality 
Rating" at 
http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Nov/0151.html
. I have no objection to this. 

Implementations: VistaTEC would be an implementer of this category. Arle 
thinks that he could provide a second implementation but cannot commit to 
having it ready until March 2013. 

Later today/tomorrow I will revise section 8.18 to reflect the naming 
change and amend the description and post back to the group. 

The only questions I have having re-read the Loc. Quality sections are 
about capturing the "agent" and "tool". Given that the Translation Agent 
Provenance data category can be used freely in combination with 
Localization Quality Issue and Localization Quality Rating then I see no 
problem with the former and if we have a data category independent 
mechanism for "tool" then I'm happy there also. Given these two 
assumptions I see no need to change any of the Localization Quality Rating 
attributes. 

So do you need all the pointer and non pointer attributes at
http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#lqprecis-implementation

all of the counter parts of these attributes have been dropped. If wen 
drop them for lqprecis too that would mean there will be no global markup 
for lqprecis, just local. For lq issues there is now just global rule 
attributes to point to standoff list of issues. but lq precis doesn't have 
a counterpart here.

In summary, what you did so far is not enough to keep lqprecis or whatever 
we will call it here. Please take the time to think carefully what 
mechanisms you really need, and do it soon.

Best,

Felix
Jirka, is this enough information that you can proceed with the schema's? 

Phil.


************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the sender immediately by e-mail.
www.vistatec.com
************************************************************


************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the sender immediately by e-mail.

www.vistatec.com
************************************************************