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

Re: unclarity about xml:lang position

From: David G. Durand <dgd@cs.bu.edu>
Date: Mon, 30 Nov 1998 14:55:29 -0400
Message-Id: <v0401170bb288997f7ba3@[24.0.249.126]>
To: Jim Davis <jdavis@parc.xerox.com>, w3c-dist-auth@w3.org
At 12:25 PM -0400 11/18/98, Jim Davis wrote:
>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."

A property may be in more than one language. Therefore the _full_ XML rules
are the only ones that make sense.

It's not a matter of which single place the value can be attached because
there's no guarantee that there's only a single language.

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

Since the lang attribute can be in either place, there's never a need to
make up "placeholder" elements.

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

Only ones that use more than one element in a property will be
unsearchable, and that seems to be acceptable to people. (_I_ don't think
it's acceptable for long, but it would be irresponsible for us to
standardize structured searching with the XML Querying and linking stuff
going on in parallel).

>So I think this interpretation must be wrong.  Do you agree?

yes, but not for the reasons you attest.

  -- David
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________
Received on Monday, 30 November 1998 14:56:33 GMT

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