Re: Status of Bugzilla Bug 10, Round-tripping various information in properties

(1) I support adding an explicit recommendation that servers
preserve namespace prefixes in property values.  I'm neutral
on whether we use the term "SHOULD" in that recommendation.

(2) I do not support adding a recommendation that comments be
preserved, since I have seen no use cases proposed that require this.

Cheers,
Geoff

Julian wrote on 12/22/2005 10:51:15 AM:

> 
> Hi,
> 
> I'd like to understand where we stand regarding property value round 
> tripping. Proposed text was posted in BugZilla (see 
> <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10>), and as far 

> as I can tell, two questions were left and sent to the mailing list for 
> discussion?
> 
> 1) We're trying to encourage servers to preserve namespace prefixes, 
> thus making it a SHOULD level requirement.
> 
> 2) Is there any interest in comments being preserved?
> 
> Re 1): there was little feedback on that, expcet for Wilfredo who's 
> concerned that people may be reyling on XML serializers that throw out 
> that information. Do people think that therefore SHOULD is too strong, 
> or would we just have to live that some servers wouldn't be able to do 
> it (it's not a MUST, after all).
> 
> Re 2): I don't think we got any feedback on this. As XML parsers are not 

> required to pass on information from comments, I'm inclined to say: not 
> a SHOULD (thus leave it in the bag of optional things servers can always 

> do).
> 
> So please try to give feedback on these two questions, and on the 
> suggested text in BugZilla. Hopefully then it can make it into the next 
> draft.
> 
> Best regards,
> 
> Julian
> 
> -- cut --
> 
> 4.4  Property Values
> 
>     The value of a property is always a (well-formed) XML fragment.
> 
>     XML has been chosen because it is a flexible, self-describing,
>     structured data format that supports rich schema definitions, and
>     because of its support for multiple character sets.  XML's self-
>     describing nature allows any property's value to be extended by
>     adding new elements.  Older clients will not break when they
>     encounter extensions because they will still have the data specified
>     in the original schema and MUST ignore elements they do not
>     understand.
> 
>     XML's support for multiple character sets allows any human-readable
>     property to be encoded and read in a character set familiar to the
>     user.  XML's support for multiple human languages, using the "xml:
>     lang" attribute, handles cases where the same character set is
>     employed by multiple human languages.  Note that xml:lang scope is
>     recursive, so a xml:lang attribute on any element containing a
>     property name element applies to the property value unless it has
>     been overridden by a more locally scoped attribute.  Note that a
>     property only has one value, in one language (or language MAY be 
left
>     undefined), not multiple values in different languages or a single
>     value in multiple languages.
> 
>     A property is always presented 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:
> 
>        <title xmlns="http://www.example.com/ns/"></title>
> 
>     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:
> 
>     For the property name Element Information Item itself:
> 
>        [namespace name],
> 
>        [local name],
> 
>        [attributes] named "xml:lang" or any such attribute in scope,
> 
>        [children] of type element or character.
> 
>     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.
> 
>     On Attribute Information Items:
> 
>        [namespace name],
> 
>        [local name] and
> 
>        [normalized value].
> 
>     On Character Information Items::
> 
>        [character code].
> 
>     Future revisions of this specification may also require to preserve
>     namespace prefixes for child elements of the property 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).]]
> 
>     XML Infoset attributes not listed above MAY be preserved by the
>     server, but clients MUST NOT rely on them being preserved.
> 
>     Also note that whitespace inside values is always significant, and
>     that servers MUST NOT support overriding this using the xml:space
>     attribute.
> 
> 4.4.1  Example - Property with Mixed Content
> 
>     Consider a dead property 'author' created by the client as follows:
> 
>         <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>
> 
>     When retrieving the property, a server may return:
> 
>         <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 &lt;RFC2518&gt;.
>             </x:notes>
>           </author>
>         </D:prop>
> 
>     Note:
> 
>     o  The [prefix] for the property name itself was not preserved, 
being
>        non-significant,
> 
>     o  attribute values have been rewritten with double quotes instead 
of
>        single quotes (quoting style is not significant), and attribute
>        order has not been preserved,
> 
>     o  the xml:lang attribute has been returned on the property name
>        element itself (it was in scope when the property was set, but 
the
>        exact position in the response is not considered significant as
>        long as it is in scope),
> 
>     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
> 
>     o  the comment item was stripped (as would have been a processing
>        instruction item).
> 
>     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.
> 
>