Re: issue-51 too many global rules

Hi Yves, all,

good points. It seems that both aspects may be interrelated. You could
resolve the "title" attribute issue by first converting HTML to XLIFF. Here
you make use of the mtConfidence score at a "target" element (I think).
Of course using ITS mtConfidence score at XLIFF "target" doesn't work (your
second point). But maybe that's no important use case, only for
locQualityIssueRef?

About "we don't care" ... it seems that the main format for adding this
metadata is XLIFF. So there is no need to have an XPath based mechanism to
accomodate many formats, but a mapping between ITS metadata to XLIFF. I
table could do too ...

Felix

2012/10/2 Yves Savourel <ysavourel@enlaso.com>

> 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.****
>
> ** **
>
> -yves****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Felix Sasaki [mailto:fsasaki@w3.org]
> *Sent:* Tuesday, October 02, 2012 5:57 AM
> *To:* public-multilingualweb-lt@w3.org
> *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.****
>
> ** **
>
> Thoughts?****
>
> ** **
>
> Felix****
>
> ** **
>
> --
> Felix Sasaki****
>
> DFKI / W3C Fellow****
>
> ** **
>



-- 
Felix Sasaki
DFKI / W3C Fellow

Received on Tuesday, 2 October 2012 12:38:26 UTC