- From: <bugzilla@soe.ucsc.edu>
- Date: Sat, 31 Dec 2005 04:47:34 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10
julian.reschke@greenbytes.de changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu
Status|ASSIGNED |NEW
Version|-08 |-09
------- Additional Comments From julian.reschke@greenbytes.de 2005-12-31 04:47 -------
Here's the full set of differences ("OLD" is draft-ietf-rfc2518bis-09, "NEW" is
the text I have proposed in November, and that we've been discussing on the
mailing list). (also re-assigning to Elias for next conference call)
Section 4., para. 18:
OLD:
A property is always represented in XML with an XML element
consisting of the property name, called the "property name element".
The simplest example is an empty property, which is different from a
property that does not exist:
NEW:
A property is always represented with an XML element consisting of
the property name, called the "property name element".
The simplest example is an empty property, which is different from a
property that does not exist:
(note the redundant "...in XML..." -- is there another way to represent a
property that the spec describes?)
Section 4., para. 19:
OLD:
<R:title xmlns:R="http://www.example.com/ns/"></R:title>
NEW:
<title xmlns="http://www.example.com/ns/"></title>
(this is about the simplest possible property, and adding a namespace prefix
here IMHO is just confusing)
Section 4., para. 20:
OLD:
The value of a property appears inside the property name element.
The value may be any kind of well-formed XML content, including both
text-only and mixed content. In the latter case, servers MUST
preserve certain aspects of the content (described using the
terminology from [W3C.REC-xml-infoset-20040204]).
NEW:
The value of the property appears inside the property name element.
It may be any kind of well-formed XML content, including both text-
only and mixed content. In the latter case, servers MUST preserve
certain aspects of the content. Using the terminology from [REC-XML-
INFOSET], the following rules apply:
(I think "The value of *the* property..." is better here, because this is a
continuation from the previous section; also even to a non-native english
speaker having two sentences start with the same words looks bad (why this
change???)
Section 4., para. 22:
OLD:
[namespace name]
[local name]
[attributes] named "xml:lang" or any such attribute in scope
[children] of type element or character
NEW:
[namespace name],
[local name],
[attributes] named "xml:lang" or any such attribute in scope,
[children] of type element or character.
(Punctuation)
Section 4., para. 24:
OLD:
On all Element Information Items in the value:
[namespace name]
[local name]
[attributes]
[children] of type element or character
NEW:
On all Element Information Items that are descendants of the property
name element:
[namespace name],
[local name],
[attributes] and
[children] of type element or character.
(Editorial)
Section 4., para. 29:
OLD:
On Attribute Information Items in the value:
[namespace name]
[local name]
[normalized value]
NEW:
On Attribute Information Items:
[namespace name],
[local name] and
[normalized value].
(Punctuation; also "in the value" doesn't seem to be precise to me, what does
"in" mean?)
Section 4., para. 33:
OLD:
On Character Information Items in the value:
[character code]
NEW:
On Character Information Items:
[character code].
Again, what does "in the value" mean here? Are there Character Information Items
"outside" the value?
Section 4., para. 35:
OLD:
Since prefixes are used in some XML query/handling tools, servers
SHOULD preserve, for any Information Item in the value:
[prefix]
NEW:
Future revisions of this specification may also require to preserve
namespace prefixes for child elements of the property name elements,
thus servers SHOULD preserve the [prefix] as well.
[[preserve.more.xml: Feedback if we should ask implementors to
preserve more in the future is appreciated (such as comments).]]
(I do not object to changing the language here, but "..are used in some XML
query/handling tools..." certainly doesn't help explaining the issue)
Section 4., para. 37:
OLD:
In dead properties (considered as content, like document bodies)
servers are encouraged to (MAY) preserve, for any Comment Information
Item in the value:
[content]
NEW:
(remove this; servers MAY preserve whatever they want; the introduction of a
distinction between dead and live properties doesn't make things clearer)
Section 4., para. 39:
OLD:
The XML attribute xml:space MUST NOT be used to change white space
handling. White space in property values is significant.
NEW:
Also note that whitespace inside values is always significant, and
that servers MUST NOT support overriding this using the xml:space
attribute.
(This is almost the same. The "OLD" text seems to make a PROPPATCH with
xml:space="preserve" illegal, while the "NEW" text tells servers to ignore it
should it be there; I think the latter more accurately reflects WG consensus).
Section 4., para. 42:
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>
(these seem to be identical except for whitespace between attributes)
Section 4., para. 43:
OLD:
When this property is requested, a server might return:
NEW:
When retrieving the property, a server may return:
(don't care)
Section 4., para. 44:
OLD:
<author xmlns:x='http://example.com/ns' xml:lang="en"
xmlns='http://example.com/ns'
xmlns:ns1='http://www.w3.org/1999/xhtml'>
<x:name>Jane Doe</name>
<x:uri added="2005-11-26" type="email"
>mailto:jane.doe@example.com</uri>
<x:uri added="2005-11-27" type="web"
>http://www.example.com</uri>
<x:notes>
Jane has been working way <h:em>too</h:em> long on the
long-awaited revision of <RFC2518>.
</x:notes>
</author>
Note in this example:
NEW:
<D:prop xmlns:D='DAV:'>
<author xmlns="http://example.com/ns"
xmlns:x="http://example.com/ns"
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 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 <RFC2518>.
</x:notes>
</author>
</D:prop>
Note:
(the "OLD" example is broken in at least three ways: (1) amount of whitespace in
property value changed, (2) parse errors (mismatched start/end tags), (3) usage
of undefined namespace prefix; as a general comment: if people start editing
carefully crafted XML examples, please run them through an XML parser afterwards).
Section 4., para. 45:
OLD:
o The [prefix] for the property name itself was not preserved, being
non-significant
NEW:
o The [prefix] for the property name itself was not preserved, being
non-significant,
(Punctuation)
Section 4., para. 48:
OLD:
o whitespace between tags has been preserved everywhere (whitespace
between attributes not so),
o CDATA encapsulation was replaced with character escaping (the
reverse would also be legal),
NEW:
o the [prefix] has been preserved on the child element "notes",
o whitespace between tags has been preserved everywhere (but the
fact that CDATA escaping was used is irrelevant), and
(note the absense of the statement about prefix preservation in "OLD", the
remainder seems to be editorial)
Section 4., para. 51:
OLD:
Implementation note: there are cases such as editing scenarios where
clients may require that XML content is preserved character-by-
character (such as attribute ordering or quoting style). In this
case, clients should consider using a text-only property value by
escaping all characters that have a special meaning in XML parsing.
NEW:
Implementation note:
There are cases such as editing scenarios where clients may
require that XML content is preserved character-by-character (such
as attribute ordering or quoting style). In this case, clients
should consider using a text-only property value by escaping all
characters that have a special meaning in XML parsing.
(Indentation)
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Saturday, 31 December 2005 12:47:43 UTC