Re: Fixes for editorial issues

Lisa Dusseault wrote:
> 
> 
> On Nov 21, 2005, at 10:57 AM, Julian Reschke wrote:
>>
>>> - 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.
> 
> Ah, I see.  What a pain to have to have the whole reference inline -- I 
> like having references in some external place, safe from my typos.  Both 
> ugly choices, sadly.

Just copy the definition once, fixing it where needed (and the 
automatically generated once frequently need fixing). They are safe from 
typos as long as changes to the documents are controlled (for instance, 
by a working revision control system). That being said, here's the entry 
  for XMLNS I used on RFC2518.xml:

     <reference anchor="REC-XML-NAMES" 
target="http://www.w3.org/TR/1999/REC-xml-names-19990114">
       <front>
         <title>Namespaces in XML</title>
         <author initials="T." surname="Bray">
           <organization>Textuality</organization>
           <address>
             <email>tbray@textuality.com</email>
           </address>
         </author>
         <author initials="D." surname="Hollander">
           <organization>Hewlett-Packard Company</organization>
           <address>
             <email>dmh@corp.hp.com</email>
           </address>
         </author>
         <author initials="A." surname="Layman">
           <organization>Microsoft</organization>
           <address>
             <email>andrewl@microsoft.com</email>
           </address>
         </author>
         <date month="January" year="1999" />
       </front>
       <seriesInfo name="W3C" value="REC-xml-names-19990114" />
     </reference>

>>> - 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.
> 
> If we state that namespace declarations must be preserved, doesn't that 
> mean that the server must return the property value with the same 
> namespace declarations it was originally sent with, on the same element, 
> and even including the prefix?  Because the namespace declaration 
> includes the prefix, as I understand.

Well, I would have preferred that instead of silently changing the 
document, you would have explained why you think it needs to be changed 
so that the problem can be discussed.

I don't see how the current text "namespace names in scope" makes any 
sense. If you don't like "namespace declarations" (which may imply 
something about prefixes, granted), just stick with the text we had 
before. What was wrong with it?

>>> 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?
>>
> 
> Presumably if we require the server to store the namespace (the text no 
> longer says to store the namespace name), then that means that the 
> server can remember that the element "foo" was declared in namespace 
 > ...

OK, case closed. The previous text is back in. No further discussion is 
needed.

> ...

Best regards, Julian

Received on Monday, 21 November 2005 21:02:48 UTC