RE: Issue: XML_LANG_CLARIFY

Unless someone has a good argument against having the lang attribute
appear on the property node, I agree with JimW that it should appear
on the property node.

Cheers,
Geoff

-----Original Message-----
From: Jim Whitehead [mailto:ejw@cse.ucsc.edu]
Sent: Wednesday, April 25, 2001 2:29 PM
To: WebDAV WG
Subject: Issue: XML_LANG_CLARIFY


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.

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

----

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

Received on Wednesday, 25 April 2001 14:45:54 UTC