W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 22 Dec 2005 16:51:15 +0100
Message-ID: <43AACB73.9000408@gmx.de>
To: webdav <w3c-dist-auth@w3.org>


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 

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 

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 

Best regards,


-- 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

    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

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'
            <x:uri type='web' added='2005-11-27'
            <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>]]>.

    When retrieving the property, a server may return:

        <D:prop xmlns:D='DAV:'>
          <author xmlns="http://example.com/ns"
            <x:name>Jane Doe</x:name>
            <x:uri added="2005-11-26" type="email"
            <x:uri added="2005-11-27" type="web"
            <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;.


    o  The [prefix] for the property name itself was not preserved, being

    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.
Received on Thursday, 22 December 2005 15:53:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:34 UTC