Subject: RE: Issue: XML_LANG_CLARIFY

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 25 Apr 2001 14:40:32 -0700

> Jim Whitehead wrote:
> > So I think this interpretation must be wrong.  Do you agree?

Just a minor clarification: these words were written by Jim *Davis*, in his
original post on the subject.

I recommend re-reading the original thread.

- Jim

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 25 Apr 2001 11:29:07 -0700

This issue is another way of attacking the XML property round-trip behavior
problem.

The issue was originally raised by Jim Davis:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0203.html

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?

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.

----

Section 12.13.2 of RFC 2518 currently states:

   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.

- Jim

---

From: Laurie Harper <[email-masked]>
Date: Wed, 25 Apr 2001 16:53:17 -0400

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

I'd say it was doubly wrong, since the effect of an xml:lang attr on any
ancestor element of the property should equally be persisted.

L.
-- 
http: www.holoweb.net/~zodiac/   |   jabber: zodiac(@)jabber!org
email: zodiac(@)holoweb!net      |   icq: #78724820
-----------------------------------------------------------------
   condom: general protection error, child process produced.