Re: LocQualityProfileRef target

Hi Arle, all,

thanks a lot for this thread and pushing this discussion. Again I am 
only wondering whether we should gather this in the wiki  in a dedicated 
ITS2 <> MQM page. We have already touched so many points (mapping of 
types, MQM serialization options and how they relate to ITS2, role of 
profileRef, ...) so that it may be hard to remember the various options.

Best,

Felix

Am 03.07.13 12:45, schrieb Arle Lommel:
> Hi all,
>
> Just as a follow up to my last email, I thought I'd jot down some 
> issues since I probably will not make it to the call today (I have an 
> off-site meeting). These are some issues to consider.
>
> *1. One- or two-file profiles?*
> From the MQM perspective, we want to have a master repository of 
> information on issue types that includes extensive metadata, such as 
> examples, notes, and translations of names into multiple languages. 
> Such a repository will be required if implementers are to have 
> guidance on how to implement categories (going beyond bare labels). 
> Such a repository would have quite a bit of metadata about each 
> category, including at least the following:
>
>   * Full name(s) for the category (as distinct from the token name),
>     possibly in multiple languages. (We want to support users who are
>     not working in English.)
>   * Explanations of the category (again, possibly in multiple languages)
>   * Usage notes to guide users in how to apply categories (along the
>     lines of the notes in the ITS 2.0 table of issue types)
>
>
> The issue is that once we start putting all this metadata in and want 
> to ensure that it is kept up to date, it is bad data management 
> practice to start stuffing it into every metrics declaration file. The 
> metrics declaration file (= the target of the profileRef) should be as 
> simple and straight-forward as possible.
>
> So I'm wondering if we need to take a TBX approach in which there is a 
> master repository with all the metadata and then the actual metrics 
> declaration just refers to the issue types from that repository, but 
> doesn't include all this metadata.
>
> The pro for this is that it makes for much cleaner data management and 
> a simpler way to declare a metric (I'm guessing we'd see an 80-90% 
> reduction in verbosity in the metrics declarations). The declaration 
> would need to invoke the particular master repository it is using (I'd 
> envision keeping an archived of numbered versions), but once that is 
> done, it could be very simple. If you want to exchange metrics, you 
> send a simple file around, not the full (and bloated) declaration.
>
> The drawback is that you then need two files if you want all the 
> metadata so the developer cannot simply load a single file. In 
> addition, because you need two files, single-step parsing and 
> validation of metrics data embedded in a document is harder since 
> there is no single schema that contains all the constraints about what 
> you need in it. This is the same issue TBX faces with the DTD+XCS file 
> construct and there are those who don't like it. In principle, 
> however, if we don't insist on a single specific location, a tool 
> developer could cache that master declaration locally and use it 
> locally, taking out some of the pain of a two-file approach.
>
> My own inclination is to take a two file approach. It is the only way 
> I can see to preserve integrity in MQM over the long haul.
>
> I'm not sure if my argument here is clear or not (I'm assuming a lot 
> of background knowledge) and if it isn't, I'll try to explain it in 
> our next ITS interest group call.
>
> *2. A generic mechanism?*
> This topic has already emerged, but the question is whether we want to 
> develop a generic mechanism to describe a profile ref or if I should 
> just focus on an MQM-specific mechanism. I would be inclined to 
> develop more generic mechanisms (keeping MQM in mind, obviously), 
> possibly feeding into a companion W3C recommendation in the future so 
> that there is a structure to the profileRef that a future version of 
> ITS 2.0 could mandate :-)
>
> I would also then want to give ITS 2.0 a privileged place in this 
> mechanism by mandating that a profileRef contain a mapping to ITS 2.0 
> categories so that the connection is made transparent. (The issue of 
> one- vs. two-file solutions addressed above impacts this to some 
> extent, since in a two-file solution, the mapping would be in the 
> master declaration as metadata, but the actual metric declaration file 
> would not contain this.)
>
> If we go with a generic mechanism, I would then use it for defining 
> MQM formally, helping unify these approaches.
>
>
>
> I'm sure there are other issues, but I'm hoping that the files I sent 
> yesterday and some of this discussion will spark enough 
> interest/discussion that I will know that there is real interest out 
> there in tackling some of these issues.
>
> Best,
>
> Arle