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

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:-)

[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