Re: Fixes for editorial issues

Lisa Dusseault wrote:
> Thanks for the help, I've incorporated many of these changes, and the 
> diff format was especially useful for the whitespace-after-hyphen 
> problem as well as for the symbolic references. Here's what I haven't 
> entirely incorporated:
> 
> - Bug 30, I didn't apply the XML line breaks exactly as you did but 
> tried to retain the indentation as much as possible for readability. 
> Still I think it achieves valid XML-ness now.

Well, it still doesn't parse because of

         <D:lockroot>
           <D:href
           >http://example.com/workspace/webdav/proposal.doc<
           /D:href>
         </D:lockroot>

Dunno why I didn't catch it, but it's a good indicator why the XML in 
the spec should be checked by an XML parser, not us.

> - Bug 41, Nesting XML definition subsections, e.g. moving "depth XML 
> element" as a subsection of "activelock XML element" and similar 
> sub-section moves: This wasn't an error in RFC2518bis, it was an 
> intentional editorial choice to flatten the subsection hierarchy. It's 
> just a list of definitions, and a flat list seems more readable. Plus, 
> with the nesting subsections, some section headers (like "propstat" 
> definition section in your version) start to have four section numbers 
> ("Section 13.9.1.1.") and either get lost or confusing in the TOC.

The elements were grouped in RFC2518, and I think that was fine. If 
there was consensus for this change, it would also need to be re-sorted. 
Anyway, I think this change should be reverted.

The TOC is not an issue here, the TOC depth can be configured (although 
I personally prefer to have all entries in the TOC, that's the place 
where I look first, after all).

> - Bug 168 I applied the symbolic references changes, but I may make 
> further changes in the future. Sometimes it's not very helpful to the 
> reader just to have an RFC number and not a spec name or even acronym -- 
> but we can have both. And perhaps you can suggest how to fix this ugly one:
> 
> The XML namespace extension [W3C.REC-xml-names-19990114] is also used
> in this specification in order to allow for new XML elements to be
> added without fear of colliding with other element names.

Just like for XML. In-line the reference and choose a good anchor name, 
preferably the same as in RFC2518.

> - Bug 174 is not strictly editorial, it actually changes the meaning of 
> a requirement. Here's your suggested text:
> 
> When the property value contains
> further XML elements, namespace declarations that are in scope for that 
> part of
> the XML document apply within the property value as well, and MUST
> be preserved in server storage for retransmission later.

I would have classified it as editorial. Could you please explain why 
you changed it in the first place? Anyway, I think that "namespace 
declarations" are to be preserved.

> In the context of the whole sentence, your change would state that the 
> namespace *declarations*... MUST be preserved in server storage. 
> Previously the sentence only stated that the namespace must be preserved 
> in server storage. Perhaps we can find another phrasing entirely.

Could you please explain what "preserving the namespace name" actually 
means?

Best regards, Julian

Received on Monday, 21 November 2005 18:58:38 UTC