[Bug 10] Round-tripping various information in properties

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10

julian.reschke@greenbytes.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |
            Version|-09                         |-10



------- Additional Comments From julian.reschke@greenbytes.de  2006-01-10 13:11 -------
I guess everybody has been eager to see on how the two spec proposals converge,
right?

I just went through the remaining diffs (compared to the WG draft as of
2006-01-06), got rid of some, but still need to point out a few problems. Below
are the diffs, with the important ones on top, the rest being punctuation. As
usual the diffs can be seen in context at
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz010>.

(Elias to re-schedule)

Section 4., para. 37:
OLD:

    Since prefixes are used in some XML query/handling tools (XPath and
    XML Schema, for example), servers SHOULD preserve, for any
    Information Item in the value:

NEW:

    Since prefixes are used in some XML vocabularies (such as XPath and
    XML Schema), servers SHOULD preserve, for any Information Item in the
    value:

(Usage of prefixes is not restricted to a specific group of tools, XPath and XML
Schema being the most widely known just happen to be in that category)


Section 4., para. 39:
OLD:

    XML Infoset attributes not listed above MAY be preserved by the
    server, but clients MUST NOT rely on them being preserved.  The above
    rules would also apply by default to live properties, unless defined
    otherwise.  Note that today many server implementations do not
    preserve prefixes and so in practice clients have to handle prefix
    rewriting.

NEW:

    XML Infoset attributes not listed above MAY be preserved by the
    server, but clients MUST NOT rely on them being preserved.  The above
    rules would also apply by default to live properties, unless defined
    otherwise.

(I think we need to be careful not to confuse normative text with backwards
compatibilty notes -- servers that implement this spec SHOULD preserve prefixes;
following this with a statement that servers don't weakens the requirement and
furthermore is incorrect; as far as I can tell, there's no a single server out
there yet which claims to implement RFC2518bis).

Finally, in...



Section 4., para. 43:
OLD:

      <D:prop xml:lang="en">
        <x:author xmlns:x='http://example.com/ns'>
          <x:name>Jane Doe</x:name>
          <!-- Jane's contact info -->
          <x:uri type='email'
                 added='2005-11-26'>mailto:jane.doe@example.com</x:uri>
          <x:uri type='web'
                 added='2005-11-27'>http://www.example.com</x:uri>
          <x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
            Jane has been working way <h:em>too</h:em> long on the
            long-awaited revision of <![CDATA[<RFC2518>]]>.
          </x:notes>
        </x:author>
      </D:prop>

NEW:

        <D:prop xml:lang='en' xmlns:D='DAV:'>
          <x:author xmlns:x='http://example.com/ns'>
            <x:name>Jane Doe</x:name>
            <!-- Jane's contact info -->
            <x:uri type='email'
                   added='2005-11-26'>mailto:jane.doe@example.com</x:uri>
            <x:uri type='web'
                   added='2005-11-27'>http://www.example.com</x:uri>
            <x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
              Jane has been working way <h:em>too</h:em> long on the
              long-awaited revision of <![CDATA[<RFC2518>]]>.
            </x:notes>
          </x:author>
        </D:prop>


Section 4., para. 45:
OLD:

      <D:prop><author xmlns:x='http://example.com/ns' xml:lang="en"
              xmlns='http://example.com/ns'
              xmlns:h='http://www.w3.org/1999/xhtml'>
          <x:name>Jane Doe</x:name>
          <x:uri   added="2005-11-26" type="email"
            >mailto:jane.doe@example.com</x:uri>
          <x:uri   added="2005-11-27" type="web"
            >http://www.example.com</x:uri>
          <x:notes>
            Jane has been working way <h:em>too</h:em> long on the
            long-awaited revision of &lt;RFC2518&gt;.
          </x:notes>
        </author>
      </D:prop>
    Note in this example:

NEW:

        <D:prop xmlns:D='DAV:'>
          <author xmlns="http://example.com/ns"
                     xmlns:x="http://example.com/ns"
                     xmlns:h="http://www.w3.org/1999/xhtml"
                     xml:lang="en">
            <x:name>Jane Doe</x:name>
            <x:uri added="2005-11-26" type="email"
            >mailto:jane.doe@example.com</x:uri>
            <x:uri added="2005-11-27" type="web"
            >http://www.example.com</x:uri>
            <x:notes>
              Jane has been working way <h:em>too</h:em> long on the
              long-awaited revision of &lt;RFC2518&gt;.
            </x:notes>
          </author>
        </D:prop>
    Note in this example:


...we still have non-wellformed XML (again the recommendation to run examples
through an XML parser if they aren't used as proposed and checked).

The remainder is punctuation (I wouldn't report if I wouldn't think that adding
it enhances readability).


Section 4., para. 22:
OLD:

       [namespace name]

NEW:

       [namespace name],


Section 4., para. 23:
OLD:

       [local name]

NEW:

       [local name],


Section 4., para. 24:
OLD:

       [attributes] named "xml:lang" or any such attribute in scope

NEW:

       [attributes] named "xml:lang" or any such attribute in scope,


Section 4., para. 25:
OLD:

       [children] of type element or character

NEW:

       [children] of type element or character.


Section 4., para. 27:
OLD:

       [namespace name]

NEW:

       [namespace name],


Section 4., para. 28:
OLD:

       [local name]

NEW:

       [local name],


Section 4., para. 29:
OLD:

       [attributes]

NEW:

       [attributes],


Section 4., para. 30:
OLD:

       [children] of type element or character

NEW:

       [children] of type element or character.


Section 4., para. 32:
OLD:

       [namespace name]

NEW:

       [namespace name],


Section 4., para. 33:
OLD:

       [local name]

NEW:

       [local name],


Section 4., para. 34:
OLD:

       [normalized value]

NEW:

       [normalized value].


Section 4., para. 36:
OLD:

       [character code]

NEW:

       [character code].


Section 4., para. 38:
OLD:

       [prefix]

NEW:

       [prefix].



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

Received on Tuesday, 10 January 2006 21:12:02 UTC