- From: Felix Sasaki <fsasaki@w3.org>
- Date: Tue, 2 Oct 2012 14:37:56 +0200
- To: Yves Savourel <ysavourel@enlaso.com>
- Cc: public-multilingualweb-lt@w3.org
- Message-ID: <CAL58czqu8jx0SpNw2RzZFXUUmbnweM7LMwtSfmO=hWgcTSE+WA@mail.gmail.com>
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