- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Wed, 18 Nov 1998 09:59:19 -0800
- To: Jim Davis <jdavis@parc.xerox.com>, w3c-dist-auth@w3.org
Jim Davis writes: > 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? Yikes! Well, the intent of the requirement in the DAV spec. is that the server should store language tagging information, if it affects the XML elements in the property value. So, I would expect a DAV server to store this language tagging information even if xml:lang appears in a higher-level parent element, and doesn't directly appear in an XML element in the property value. To not do so would result in a loss of information, and a loss of this language tagging information, which results in poor handling of international content. > 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." This should be amended to read something like "Language tagging information in the property's value, or with scope which affects XML elements in the property's value (following scoping rules for the "xml:lang" attribute, if present) MUST ..." There probably also needs to be 1-2 examples, and a brief discussion of xml:lang scoping. > At least one implementor has interpreted this to mean it must be > on the child. I hope that implementor will modify their code so that xml:lang information is persistently stored and subsequently retrievable, no matter where the xml:lang attribute appears. > > 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> This seems quite reasonable to me, and is the intended behavior. > 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. I agree, this has bad consequences. > 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? Quite true! Thank you for performing this interoperability test, and for airing contentious points so rapidly. - Jim
Received on Wednesday, 18 November 1998 13:15:03 UTC