Re: LocQualityProfileRef target

+1

Phil
Twitter: philinthecloud
Skype: philviathecloud


On 5 Jul 2013, at 09:20, "Jörg Schütz" <joerg@bioloom.de> wrote:

> +1 for a dedicated wiki section
>
> This would be great to better follow and contribute to the discussion
> instead of browsing through various email threads.
>
> Cheers -- Jörg
>
> On July 04, 2013 at 19:11 (CEST), Felix Sasaki wrote:
> > 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
>
>

************************************************************
VistaTEC Ltd. Registered in Ireland 268483. 
Registered Office, VistaTEC House, 700, South Circular Road, 
Kilmainham. Dublin 8. Ireland. 

The information contained in this message, including any accompanying 
documents, is confidential and is intended only for the addressee(s). 
The unauthorized use, disclosure, copying, or alteration of this 
message is strictly forbidden. If you have received this message in
error please notify the sender immediately.
************************************************************

Received on Friday, 5 July 2013 08:28:57 UTC