- From: Jim Davis <jdavis@parc.xerox.com>
- Date: Wed, 18 Nov 1998 08:25:51 PST
- To: w3c-dist-auth@w3.org
It is unclear from the spec (12.13.2) where exactly the xml:lang attribute must appear in the XML request body in order to be stored. May it appear anywhere in the XML tree (even, eg as an attribute of the DAV:propstore element)? Or must is appear on a child of the property element within the DAV:prop? The XML spec says clearly that xml:lang may appear anywhere, and that is has scope over all children: "The intent declared with xml:lang is considered to apply to all elements within the content of the element where it is specified, unless overridden with another instance of xml:lang." On the other hand the DAV spec says: "Language tagging information in the property's value (in the "xml:lang" attribute, if present) MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND." At least one implementor has interpreted this to mean it must be on the child. We need clarity on this, as it affects interoperability. To elaborate, can I say <D:set> <D:prop> <D:displaynname xml:lang="NL">Kikkers in de koek</D:displayname> </D:prop> </D:set> Or do I have to push the attribute down into the child, as in <D:set> <D:prop> <D:displaynname> <X:foo xml:lang="NL">Kikkers in de koek</X:foo> </D:displayname> </D:prop> </D:set> Note that the latter interpretation has two very bad consequences: 1) Since the client has to invent a placeholder element, and there's no obvious choice for the name of the element, it shoots interoperability. No two clients will use the same element name for this placeholder, and hence the values won't be comparable. 2) Since the current DASL base search protocol can't search properties whose values are structures (ie. are elements, on the wire) no language tagged property value will be searchable. So I think this interpretation must be wrong. Do you agree? If so, can we modify draft 10 and add an explicit example clarifying this? Sorry not to notice this sooner but of course it's only when one does interoperability testing that one discovers these differences of interpretation. That's why we do it at all, right? Jim ------------------------------------ http://www.parc.xerox.com/jdavis/ 650-812-4301
Received on Wednesday, 18 November 1998 11:28:05 UTC