RE: unclarity about xml:lang position

I'm probably just slow but the second implementation seems to just be plain
wrong. Our requirement is that you support xml:lang as defined in the XML
spec. The XML spec says xml:lang can show up anywhere, therefore you must
support it showing up anywhere. The XML spec says that xml:lang is scoping,
therefore you must support its scoping effects. So if I send you:

<D:set xml:lang="NL">
	<D:prop>
		<D:displaynname>
			<X:foo>Kikkers in de koek</X:foo>
		</D:displayname>
	</D:prop>
</D:set>

Then you better indicate in the PROPFIND response that X:foo has an
xml:lang="NL" associated with it. You can express this directly on the
property or on a higher level element but the data has to be there. The
requirement for responses is semantic, not syntactic, equivalence.

Of course we could clarify the spec, but short of providing an entire XML
tutorial we must assume that the reader is familiar with XML. This isn't an
issue for DAV, this is an issue for XML.

			Yaron


-----Original Message-----
From: Jim Whitehead [mailto:ejw@ics.uci.edu]
Sent: Wednesday, November 18, 1998 9:59 AM
To: Jim Davis; w3c-dist-auth@w3.org
Subject: 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 15:49:09 UTC