Re: Review of the the DM pre CR version (Re: Final round of Direct Mapping spec changes; please review to prepare for CR)

Ivan,

On Jan 26, 2012, at 8:48 AM, Ivan Herman <ivan@w3.org> wrote:

> Hey Eric, Juan
> 
> everything that I removed means that I agree with your editing and I consider the issue closed...
> 
> On Jan 26, 2012, at 14:16 , Eric Prud'hommeaux wrote:
> [snip]
> 
>> 
>> 
>>>>> - I think that for a final review leading to the CR, we should also see
>>>>> the Status of Document session. Or is it so that the Status will only be the
>>>>> boilerplate text for a CR generated by the tools you use for the
>>>>> publication? (I would expect that to be the case, but we should know...)
>>>>> 
>>>> 
>>>> I'll leave this to Eric
>> 
>> This will be a complex issue which I will take this up in thread
>> called "LC Status and implementation reports".
>> 
> 
> :-)
> 
>>>>> 
>>>>> 
>>>>>  Again my SQL knowledge... at the last telco we decided to put a quote
>>>>> around identifier to get around the character casing problem. Shouldn't ID
>>>>> be in quotes in the argument of PRIMARY KEY(ID) as well (note that the same
>>>>> statement is quoted in the text after the SQL portion where ID is in
>>>>> quotes)? The same question for the INSERT statements.
>>>>> 
>>>> 
>>>> Also added missing quotes in another example.
>>>> 
>>>> Not sure about the INSERT statements... somebody?
>>> 
>>> I don't think the INSERTs are strictly necessary as the case-folding
>>> behavior will have the same effect as if there were no case-folding.
>>> I think we should decide this based on what's more intuitive to the reader.
>>> What's more intuitive to the reader?
>> 
>> Ted made more comments on this. I'll respond to those sepparately.
> 
> Ok. I leave this to Ted then.
> 
> [snip]
> 
>>>>> 
>>>>>  Is this note really forthcoming? At the moment, we do not know whether it
>>>>> will happen. I guess it would be safer not to have a reference to a
>>>>> publication that may not materialize, ie, just remove the last sentence.
>>>> 
>>>> 
>>>> This is a note that I have planned to write with Marcelo. Remember the
>>>> hundreds of emails on this topic... if I recall, the resolution was to add
>>>> those two sentences to the spec. Michael, can you confirm?
>>> 
>>> I think we can see if there's a note by the time we get to Rec. If
>>> not, I think the sentences should go.
>>> 
> 
> O.k, this has to be checked with Michael. I do remember that we had a resolution that you and Marcelo (and Paolo?) would write such a note. But if we leave this text in, that means we cannot publish a Rec until that Note is finished and published. Do you accept that responsibility in your schedule?
> 
> If we remove this from the text, you still have a 'moral' obligation of writing the note:-), but at least you do not become a possible bottleneck:-)

Let's remove the text. I don't have time to write this in the next month. However, I will get it done :)

Is that ok Michael. 
> 
> [snip]
> 
>>>> 
>>>>> 
>>>>> 
>>>>> - Section 2.5
>>>>> 
>>>>>   SQL example: is there a reason for the tabulation that puts everything
>>>>> but "lead" and "worker" on a deeper level? I guess this is and editorial bug
>> 
>> I'm not sure I follow. Does it look like the attached 2.5.png?
>> 
> 
> You have not attached a file to the mail, but I do now... This is on Safari on Mac, the same happens on Firefox on Mac.
> 
> [snip]
> 
> 
>> 
>>>>>   I had difficulties understanding the example here. First of all, it may
>>>>> be worth to make it clear that this example refers back to the example in
>>>>> Section 2.2. But the slightly convoluted nature of unique keys, the fact
>>>>> that they overlap (see the table) makes it a little bit difficult to follow.
>>>>> 
>>>>>   I wonder whether it would not help to remove the references to the
>>>>> Department table (at least from TaskAssignments). It does not bring anything
>>>>> at this point to the user, just creates confusion...
>>>> 
>>>> 
>>>> I'll leave this to Eric
>>> 
>>> The point is exactly to show what happens when you have multi-column
>>> overlapping keys. Perhaps some text like "this is a complicated
>>> example intended to show the behavior with respect to multi-column
>>> overlapping keys" will properly calibrate the reader.
> 
> Ok. Maybe so. If we were not at CR I would propose to cut the example into two, a simpler and a more complex ones, but I recognize that this would lead to additional editorial jobs elsewhere (eg, to Juan in Appendix 3), so I let it go...
> 
> [snip]
> 
> Thanks guys!
> 
> Ivan
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> 
> 
> <Screen Shot 2012-01-26 at 14.36.02 .png>