Re: Test Suit Specs - Pointers and RefPointers

Hey Felix,

I agree that a vote on Monday would be useful to clarify this issue and
then after that I can produce the new output that has consensus within the
group and also highlight these changes to implementers. This would possibly
cause less confusion than me producing output that some people disagree on
only for it to change at a future date.

Thanks,
Leroy

On 8 November 2012 13:59, Felix Sasaki <fsasaki@w3.org> wrote:

> P.S.: Sorry, hit the "send" button too fast: I don't feel strong about
> this, just mentioning some reasons to have "pointer" info. At the end we
> might just do a majority vote during a working group call if there - but
> there is no real process for test suite design.
>
> Best,
>
> Felix
>
>
> 2012/11/8 Felix Sasaki <fsasaki@w3.org>
>
>>
>>
>> 2012/11/8 Yves Savourel <ysavourel@enlaso.com>
>>
>>> Hi Leroy, Felix, all,****
>>>
>>> ** **
>>>
>>> I do understand the preference to have pointers. It’s nice and it, in
>>> some cases, could help debugging.****
>>>
>>> ** **
>>>
>>> The issue is that to output pointer in the test result you have to carry
>>> that information in the decorated tree. But from a pure implementation
>>> efficiency viewpoint there is no reason to do that, and several reason to
>>> avoid it.****
>>>
>>> ** **
>>>
>>> In other words, if we output pointers, we force the implementers to make
>>> their implementation un-necessarily less optimal just because it’s kind of
>>> nice to see the pointers in a test output that real users will never see.
>>> ****
>>>
>>> ** **
>>>
>>> IMO the test outputs are a way to validate the results produced by an
>>> implementation, not to debug it.****
>>>
>>> As Felix noted, we didn’t have this in the 1.0 tests. I think we need a
>>> strong reason to add it for 2.0.
>>>
>>
>>
>> FELIX: My main argument would be growing complexity in 2.0 about how to
>> create ITS information. In ITS 1.0 we had a maximum of four attributes at a
>> global rule:
>>  attribute locNotePointer { string }?, attribute locNoteType { "alert" |
>> "description" }, attribute locNoteRef { xsd:anyURI }?, attribute
>> locNoteRefPointer
>> In ITS 2.0 it is *28* attributes, see
>> http://www.w3.org/TR/its20/#translation-agent-provenance-global
>> Some of these are mutally exclusive; but it seems easy to get lost when
>> you ask yourself: where does a wrong value come from, the input data or the
>> ITS metadata?
>>
>> Best,
>>
>> Felix
>>
>> ****
>>>
>>> ** **
>>>
>>> Does showing the pointer value on a given node prove that the result was
>>> obtain using that pointer?****
>>>
>>> No. A lot of process happens between the time you would add the pointer
>>> value to the decorated tree and the time you would attach the actual result
>>> information to that same node.****
>>>
>>> ** **
>>>
>>> Can we always validate the information produced by a pointer rule
>>> without showing the pointer?****
>>>
>>> The answer is yes, thus no need to output pointers values.****
>>>
>>> ** **
>>>
>>> Cheers,****
>>>
>>> -yves****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *From:* Leroy Finn [mailto:finnle@tcd.ie]
>>> *Sent:* Thursday, November 08, 2012 5:51 AM
>>> *To:* Felix Sasaki
>>> *Cc:* Yves Savourel; Pablo Nieto Caride; Fredrik Liden; Multilingual
>>> Web LT-TESTS Public
>>> *Subject:* Re: Test Suit Specs - Pointers and RefPointers****
>>>
>>> ** **
>>>
>>> Everyone,****
>>>
>>> ** **
>>>
>>> So the consensus I am seeing here is doing the following:****
>>>
>>> ** **
>>>
>>> *Current:*
>>> */html/body[1]/p[2]/span[1]            locNoteType="description"
>>> locNoteRefPointer=""        title="Comments.html#DivByZero"*****
>>>
>>>  ****
>>>
>>>
>>> *New version:*
>>> */html/body[1]/p[2]/span[1]
>>> locNoteRefPointer="Comments.html#DivByZero"
>>> locNoteType="description"    *****
>>>
>>>  ** **
>>>
>>> This means removing title or any other random name and have more
>>> consistent output using locNoteRefPointer/locNoteRef/etc.... ****
>>>
>>> ** **
>>>
>>> So this brings me to locNoteRefPointer/locNoteRef:****
>>>
>>> ** **
>>>
>>>    - Yves and Fredrik are for removing the word pointer.****
>>>    - Felix is for having pointer. ****
>>>
>>> I don't mind either though i would be *in favor of pointer*. Its an
>>> easy thing to change but I will hold back producing output till tomorrow.
>>> If no consensus is reached by tomorrow then I will go ahead for pointer and
>>> produce the output. I will have to  have to reproduce output again probably
>>> anyway so if people change there mind and more people are for dropping
>>> pointer then i will drop pointer. So if people have views on this then let
>>> me know one way or the other.****
>>>
>>> ** **
>>>
>>> Thanks,****
>>>
>>> Leroy****
>>>
>>> ** **
>>>
>>> On 7 November 2012 21:01, Felix Sasaki <fsasaki@w3.org> wrote:****
>>>
>>> ** **
>>>
>>> 2012/11/7 Yves Savourel <ysavourel@enlaso.com>****
>>>
>>> Hi all,****
>>>
>>>
>>> >> That is a good point Felix as we want to see the output as it is
>>> >> as after all these conformance tests. I haven't made any changes
>>> >> as of yet so would this mean that the output stays the same apart
>>> >> from the changes we discussed in Lyon???
>>> >
>>> > Yes, that would be my suggestion. Of course we can continue discussing
>>> > this here, but at the moment I don't see a consensus for changing this,
>>> > with at least me opposing.****
>>>
>>> I've read all the emails in this thread and I still have a hard time to
>>> understand the changes/no-changes that people are talking about. Sorry if
>>> I'm speaking on something that has been resolved already:
>>>
>>> For me:
>>>
>>> For references: Either locNote="REF:text" or locNoteRef="text" is fine.
>>> The bottom line is that the fact that the data is a reference vs the actual
>>> text is important and should be provided. It is part of the ITS information.
>>>
>>> For the pointers: I'm not sure why we need to output that information.
>>> If the text of the information is right it means it was properly resolved.
>>> My concern is that 'how' the information was obtain as far as if it was
>>> from a native ITS attribute or some markup pointed to by a rule is not
>>> really relevant for processor used in production. Carrying that information
>>> in the decorated tree is a burden to the application.****
>>>
>>>
>>>
>>> I understand, but I think this burden is important. We have seen in the
>>> "complete overriding" discussion that carrying such information can be
>>> quite helpful to understand how the technology works - even 5 years after
>>> it has been specified.
>>>  ****
>>>
>>>
>>> So I would be for something like this:****
>>>
>>>
>>> /html/body[1]/section[2]/span[1]           locNote="A division by 0 was
>>> going to be computed."  locNoteType="description"****
>>>
>>> Rather than this:****
>>>
>>>
>>> /html/body[1]/section[2]/span[1]           locNoteType="description"
>>>     locNotePointer="A division by 0 was going to be computed."****
>>>
>>>
>>> My preference would be the latter. But I realize that in the ITS 1.0
>>> test suite we did the former, see
>>>
>>> http://www.w3.org/International/its/tests/inputdata/EX-locNotePointer-attribute-1.xml
>>>
>>> http://www.w3.org/International/its/tests/expected/EX-locNotePointer-attribute-1-result.xml
>>> In the result the pointer is normalized to
>>> <o:locNoteText>A division by 0 was going to be computed.</o:locNoteText>
>>>
>>> So I can't back my position with any data in that sense.
>>>
>>> Best,
>>>
>>> Felix
>>>  ****
>>>
>>> ** **
>>>
>>> Cheers,
>>> -yves
>>>
>>> ****
>>>
>>>
>>>
>>>
>>> --
>>> Felix Sasaki****
>>>
>>> DFKI / W3C Fellow****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>
>>
>>
>> --
>> Felix Sasaki
>> DFKI / W3C Fellow
>>
>>
>
>
> --
> Felix Sasaki
> DFKI / W3C Fellow
>
>