I like the idea of an XML structure for commenting. Never thought of that myself, and haven't run into it as a practice.

Where documentation standards have been set for me, as opposed to me setting them myself, they've been similar, but not standardized. It's been a comment block at the beginning, with the name of the author, the creation date, and something short and sweet about what it's for.

Personally, I like comments in the body of the proc/function, that say what each section does, at the very least. Helps in debugging/enhancing later on. Not needed, of course, for something that's just a parameterized select or other single-statement CRUD procs.

But that's where it breaks down, isn't it? "Oh, this is so simple it can't possibly need to be commented and have full, formal documentation!" Sure, makes sense. But what's the break-point where it needs documentation? Or is it a gradient from, "needs a few comments" to "needs full-on documentation", depending on some complexity judgement of the code?