RE: unclarity about xml:lang position

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