Re: [ISSUE-34] More in mixing profiles

2012/8/8 Yves Savourel <ysavourel@enlaso.com>

> Hi Arle, all,****
>
> ** **
>
> The solution of putting several entries inside a single attribute seems,
> to me, to have a lot more cons than pros.****
>
> ** **
>
> **-   **The notation is very easy to break (e.g. escaped characters)****
>
> **-   **You need to synchronization the number and order of the parts,
> for example deleting the part N of one attribute forces you to also delete
> the part N in other attributes.****
>
> **-   **The solution forces a complex parsing of the value, not something
> easy to work with in XSLT or CSS.****
>
> **-   **Etc.****
>
> ** **
>
> I would be much more in favor of using one <span> element for each entry.*
> ***
>
> …or to simply refer to a standoff element where things could be nicely
> setup.
>

Just for the record, standoff is a preference for me as well. I just don't
see a clear / clean inline solution that conveys several quality issue
records (if we want to call them like this).

Felix


> ****
>
> ** **
>
> -ys****
>
> **-   **** **
>
> ** **
>
> *From:* Arle Lommel [mailto:arle.lommel@dfki.de]
> *Sent:* Wednesday, August 08, 2012 5:24 AM
> *To:* Multilingual Web LT Public List
> *Subject:* [ISSUE-34] More in mixing profiles****
>
> ** **
>
> Hi all,****
>
> ** **
>
> I have to apologize for all the scatter-shot emails on the quality issue
> in the past few days. A number of issues have come up. This mail addresses
> the issue of applying multiple profiles within a document.****
>
> ** **
>
> Initially Yves had suggested the idea of using QNames to allow
> tool-specific codes to be linked back to a profile. In discussion with
> Felix, I think it makes sense to generalize the use of (optional?) QName
> prefixes to the locQualityComment, locQualityType, locQualitySeverity, and
> locQualityScore attribute values. Strictly speaking these would no longer
> be QNames as I understand it since what looks like the local part in these
> attributes would not have reference to the actual profile contents, but
> would instead serve as identifiers to specify that the tool referenced the
> QName defined in the profile applies. (They would, however, be proper
> QNames in the locQualityCode attribute because they would reference
> specific items defined in the profile.)****
>
> ** **
>
> The advantage of extending these prefixes to the other attributes is that
> it would provide an easy way to specify which profile (if multiple ones are
> used) applies.****
>
> ** **
>
> So here is a code snippet that shows what this might look like, with two
> profiles—"ugly" and "pretty"—defined elsewhere in the document used to
> markup the sentence "This paragraph haves a grammatical errors”:****
>
> ** **
>
> <para>This****
>
>    *<span*****
>
> *      its:locQualityType="*****
>
> *          ugly:grammar|*****
>
> *          pretty:grammar*****
>
> *         "*****
>
> *      its:locQualityCode="*****
>
> *          ugly:GRAMMAR**|*****
>
> *          pretty:verbal_agreement*****
>
> *         "*****
>
> *      its:locQualityComment="*****
>
> *          pretty:suggested replacement\:&quot;paragraph has&quot;*****
>
> *          OR &quot;paragraphs have &quot;*****
>
> *         "*****
>
> *    >*paragraph haves*</span>* ****
>
> *  <span*****
>
> *     its:locQualityType="*****
>
> *          ugly:grammar**|*****
>
> *          pretty:grammar*****
>
> *         "*****
>
> *     its:locQualityCode="*****
>
> *          ugly:GRAMMAR|*****
>
> *          pretty:number_agreement OR incorrect_article*****
>
> *         "*****
>
> *     its:locQualityComment="*****
>
> *         pretty:suggested replacement\:&quot;a grammatical error&quot;***
> **
>
> *         OR &quot;grammatical errors&quot; OR &quot;some grammatical
> errors&quot;*****
>
> *        "*****
>
> *   >*a grammatical errors*</span>*****
>
> </para>****
>
> ** **
>
> So now, in this view, which has been formatted strangely to make it
> clearer, the prefixes allow multiple processes to put more than one value
> for an attribute into it and make it clear that BOTH apply and "sign" which
> tool did it.****
>
> ** **
>
> This has some advantages over the earlier version in that it makes it easy
> to include multiple tools’ output without worrying about one overwriting
> another.****
>
> ** **
>
> On the other hand, it does make it harder to do things like CSS styling
> since what previously would have been locQualityType="grammar" no has a
> much more complex internal syntax that makes it harder to target.****
>
> ** **
>
> The alternative is to allow nesting of elements and get a structure like
> this, adding a new locQualityProfilePointer attribute:****
>
> ** **
>
> *<para>*This****
>
>    *<span xml:id="outer"*****
>
> *      its:locQualityProfilePointer="ugly"*****
>
> *      its:locQualityType="grammar"*****
>
> *      its:locQualityCode="GRAMMAR"*****
>
> *   >*****
>
> *     <span xml:id="inner"*****
>
> *        its:locQualityProfilePointer="pretty"*****
>
> *        its:locQualityType="grammar"*****
>
> *        its:locQualityCode="verbal_agreement"*****
>
> *        its:locQualityComment="pretty:suggested
> replacement\:&quot;paragraph has&quot;*****
>
> *           OR &quot;paragraphs have &quot;**"*****
>
> *     >*****
>
>       paragraph haves****
>
> *     </span>*****
>
> *   **</span>*****
>
>   is a little better*</para>*****
>
> ** **
>
> This allows for clean CSS access and formatting, but it runs into the
> problem that in principle the span with the id value of "inner" overrides
> the span "outer", rather than being additive, but if we can specify that
> they both apply, this is an easier syntax to parse and does not rely on the
> inner syntax of the QName prefixes and list delimiters of the first
> example. It is, all in all, much cleaner.****
>
> ** **
>
> Any thoughts on which is a better solution (or suggestions for another
> alternative)?****
>
> ** **
>
> -Arle ****
>



-- 
Felix Sasaki
DFKI / W3C Fellow