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

[Bug 10] Round-tripping namespace decls in properties

From: <bugzilla@soe.ucsc.edu>
Date: Sun, 27 Nov 2005 11:34:06 -0800
Message-Id: <200511271934.jARJY6Ke000363@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org


------- Additional Comments From julian.reschke@greenbytes.de  2005-11-27 11:34 -------
Proposed replacement text for section 4.4 (also see
Note that due to the fact that this may be the issue that has been the source of
lots of discussion, I also added a real-world example. Feedback appreciated.

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

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

   (1) [namespace name],

   (2) [local name],

   (3) [attributes] named "xml:space" (present on the property name
       element itself or it's closest ancestor),

   (4) [children] of type element or character.

   For all children of the property name element additionally:

   (5) [attributes].

   Future revisions of this specification may also require to preserve
   namespace prefixes for child elements of the property elements, thus
   servers SHOULD preserve the

   (6) [prefix].

   XML Infoset attributes not listed above MAY be preserved by the
   server, but clients MUST NOT rely on them being preserved.

   Note that a property only has one single value in one language (when
   specified).  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 such as:

       <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'><![[CDATA
           Jane has working way <h:em>too</h:em> long on the
           long-awaited revision of RFC2518.

   (where an xml:lang attribute with value 'en' appeared on a parent
   element when setting the property)

   When retrieving the property, a server may return:

       <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 working way <h:em>too</h:em> long on the
           long-awaited revision of RFC2518.


   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 that
      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).

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Sunday, 27 November 2005 19:34:11 UTC

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