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

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

From: Jim Whitehead <ejw@soe.ucsc.edu>
Date: Thu, 22 Dec 2005 09:53:54 -0800
Message-Id: <014DD6E2-7167-40BF-BC1B-8084D3D55A27@cs.ucsc.edu>
Cc: " webdav" <w3c-dist-auth@w3.org>
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
I agree with Geoff, with the minor twist that I'm fine with (1) being  
a SHOULD.

- Jim

On Dec 22, 2005, at 8:24 AM, Geoffrey M Clemm wrote:

>
> (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.
> >
> >
Received on Thursday, 22 December 2005 17:54:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:12 GMT