Tuesday, January 18, 2005, 6:56:28 AM, you wrote:

> At 17:47 05/01/17, David Powell wrote:

 >>Reading the XML spec, I'm not clear that we're allowed to restrict the
 >>inheritance of xml:lang?
 >>

>  From this text, it is indeed not clear. There is an erratum that
> makes this clearer. Please see
> http://www.w3.org/XML/xml-V10-3e-errata#E01.

Good, that was one of the things that I was concerned about.

> As an aside: We should make sure that the Atom spec is very
> clear for each element that inherits (e.g. copyright,...)
> how to define the absence of such information. As experiece
> with xml:lang and other things has shown, having something
> like a 'reset' or 'neutral element' is extremely important
> every time there is inheritance, in particular for information
> that comes from different sources.

Yes, we should do this.  I think extension elements are the main
problem though.

In PaceExtensionConstruct, I proposed two classes of extension.
Simple Extension constructs were intended to be simple to interpret
and implement.

Should xml:lang apply to them?

If it does, the range of the property would be a (string, language)
pair, which would be useful for language sensitive text, but would be
unnecessary for a lot of cases. Looking at the RSS1.0 list of
extensions, most of them are not language dependant.

If it didn't apply, then Structured Extension constructs could still
be used to implement language sensitive text, but they are more opaque
which would be a disadvantage.


 >>I didn't realize this - where is it?

> Ok, here it is: The RDF Graph model doesn't deal with mixed content
> (such as typical XHTML), but the data model has a special datatype
> that in RDF/XML is indicated by the rdf:parseType="Literal" attribute.
> The problem is that whenever you use this, RDF/XML requires you to
> cut language inheritance.

The solution for RDF that I was thinking of would be to add a BNode,
and attach the parseType="Literal" content to it together with the
xml:lang and xml:base context explicitly as properties; rather than
modify the parseType="Literal" content.

It would be like a virtual Content-Language / Content-Location header.


BTW - Does a HTTP Content-Language set the default language for Atom?

-- 
Dave

Reply via email to