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

On Thu, Jan 26, 2012 at 4:01 PM, Juan Sequeda <juanfederico@gmail.com> wrote:
> 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 :)

I agree, let's remove the text.

All the best,

Marcelo



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

Received on Thursday, 26 January 2012 19:11:47 UTC