- From: Jim Whitehead <ejw@soe.ucsc.edu>
- Date: Thu, 22 Dec 2005 09:53:54 -0800
- To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- Cc: " webdav" <w3c-dist-auth@w3.org>
- Message-Id: <014DD6E2-7167-40BF-BC1B-8084D3D55A27@cs.ucsc.edu>
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 <RFC2518>. > > </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 UTC