Re: oops!

Hi Shivaram,


On Mon, Apr 04, 2005 at 08:17:35AM -0700, Shivaram Mysore wrote:
> In the "Status of Document" section, para 1, the following sentence needs to be deleted:
>  
> The XHTML <del> tag is used to indicate previous text, where the <ins> tag indicates newly added (or modified) text.
>  
> In the same section different para starting with: " The purpose of a W3C CR ..." must be put in past tense.
>  
> In the same section, last para, starting with "Publication as a CR ...." must be changed too.

I have already written a new SoD section. It's in the request to move to
PR:

	http://www.w3.org/2001/XKMS/Drafts/rqpr.html

I've been working on other parts of the document for the moment. See my
comments further down.
>  
> 1.2 Acknowledgements:
> Looks like my employer name needs to be prefixed with (formerly Sun Microsystems Inc) and similarly for Stephen Farrell.
>

I think we should reformat the ack. section. We were advised to move it to
an appendix, rather than leave it there, but this would break some links.
I think it's better to leave it there, but update it. I'll propose some
changes directly to this PUB version and ask the list to see if they agree
with them. I don't know all the affilations of people, so I hope they will
answer then... otherwise, it will be too late for changing afterwards.

> Do you think I should make these changes?  If you are making changes, I would actually make them in the pre-PR draft version with <ins> and <del> tags so that all changes are correctly captured.

I can make these changes. I'd like to keep the lock in the PUB document a little
more, as it's the one I'm verifying and preparing :) I propose to make the changes
directly to the PUB document, as it'll become the final one and just add
two more entries to the changelog. One for the updated ack. section and
the other one for the spaces and pre formatting I am fixing (see below).

I'll wait until tomorrow to see if another pair of eyes detects something
wrong on the ins/del things I did. If this is not the case, then I'll
commit the version I arranged. Note that I made it correct vis-a-vis the
use of ins:del, but it became invalid XHTML because of it (until you run
my script). If you edit that page, then you'll have to do it directly on
the source code, not with Amaya and save it with some tool other than
Amaya. Otherwise all the changes I did will move.

When you come back on Wed, we can discuss the changes and finish them
together. I think it would be a good idea to try to schedule the review
meeting to happen either next week or the week afterwards and work towards
finishing the docs. in time for the review.

> I would also remove the granual date wise change log in Appendix E and just retain "Specification Changes between PR & CR" Section.

Will do so.

The changes I have done:

- Fixed pre formatting so that it doesn't overflow the boxes (and
  hopefully can be printed in a single page) in the following pars.:
  [101] [106] [118] [210] [243]. In some cases, I reindented those
  schema citations so that they were homogenous with the rest of the
  citations. I didn't touch the .xsd file.

- Added missing spaces, most notably to separate a section number and the
  first letter.

- An ID was duplicated (it was some par nnn.a with a trailing nnn id).

- [118] added the missing minor status codes (done directly on your
  draft version).

You can see those changes in the PUB version already.

Three questions for you or for native english speaking persons. I haven't
applied these changes as I'm waiting for feedback first.

- Sometimes the spec uses ex. and sometimes e.g. to say "for example".
  I propose we change all the ex. to e.g., as it's the standard
  way to say it.

- Sometimes the spec. uses the following phrase to say that a given
  element cannot appear as a child of another one:

    [128a]RespondWith MUST NOT be present in CompoundRequest element.

The english sounds broken to me there, as if an article were missing.
How about changing it to:

    [128a]RespondWith MUST NOT be present in a CompoundRequest element.

or

    [128a]RespondWith MUST NOT be present inside a CompoundRequest element.

This happens in a couple of par. I noted down [128a], [132], [205], but
there may be others.

- Is there any reason why sometimes the spec uses html:i and sometimes
  html:em, and likewise for html:b and html:strong? If possible, we should
  try to use em and strong.

---

If you don't agree with any of my changes, please tell me so and I can
come back to the previous version.

-jose