RE: issue-51 too many global rules

Hi Felix, all,


That make sense for the information part: all the data categories of the second list basically need to be specified locally to be truly useable.


But it would also remove two capabilities:


-    The capability to associate those data category with attribute values. We all know it’s not recommended to have translatable attributes, but then how do you associate mtConfidence with the HTML5 title attribute for example? Maybe the answer is “you don’t”. I’m just pointing the potential issue.


-    The capability to map existing markup in other vocabulary that have the same functionality as the ITS data categories. Granted: it’s unlikely to be a real use case in many cases: I’d be surprised to see the same semantics as Disambiguation anywhere else. But there is at least one case where a pointer would be handy: the pointer for the attribute that points to the standoff markup for Localization Quality Issue in XLIFF 2.0. We cannot use its:locQualityIssuesRef because <mrk> doesn’t allow non-XLIFF attributes. It means an ITS-only-aware tool would not be able to see to associate a localization quality issue with the content it pertains to. But maybe we don’t care.







From: Felix Sasaki [] 
Sent: Tuesday, October 02, 2012 5:57 AM
Subject: issue-51 too many global rules


Hi all,


as an input to issue-51, to the "global rules" part. I went through the new data categories. Below are some proposals. In the cases there the "main function of global rules, to define stable information about a document format" (adapted from Yves' mail), I propose to drop global rules.


- Domain, LocaleFilter, external resource, target pointer, preserve space, allowed characters, storage size, id value: keep global rules as is.


- QualityIssue, Quality Precis, Disambiguation, mtConfidence, text analysis annotation, provenance: drop global rules. It seems that rules here don't fulfill the main function mentioned above. That is also related to the aspect of adding a closed set of metadata values, like "yes" or "no" for translate. That makes sense for a document format, e.g. "all code elements are translatable". But it doesn't make sense for the six data categories: they don't add a closed set but rather open sets of values, e.g. mtConfidence score =0.5. These will probably not be specific to a document format.






Felix Sasaki

DFKI / W3C Fellow


Received on Tuesday, 2 October 2012 12:27:09 UTC