Monday, January 17, 2005, 6:39:49 AM, you wrote:
> On Jan 15, 2005, at 9:30 AM, David Powell wrote: >> PaceExtensionConstruct hopes to provide a basis for a mapping Atom to >> models such as RDF [1], ER, and OO. I'm currently doing some work to >> see >> whether there is anything in Atom that makes this unnecessarily >> difficult. >> >> I think that Atom's use of xml:lang is likely to be a significant >> problem to many implementors. I've posted PaceSimpleLanguageTagging >> explaining the problem. > I'm fairly unconvinced that this is will loom very large in the > universe of implementor problems. For an atom implementation where content is entered via HTML forms, or from an existing CMS - then this isn't a problem. The user won't be able to scatter xml:lang's everywhere. But for an implementation based on Atom Protocol, the server needs to preserve all of this stuff. > If it turns out that it's really an > issue, couldn't you achieve the desired effect by restricting xml:lang > to appear only on atom:entry and atom:feed? See my reply to Martin. Restricting the position of xml:lang could make things worse, unless we also restrict its inheritance - which I'm not sure that we are allowed to do. What do you think about only allowing it on atom:content and on Text constructs? > I have to admit that I'm having trouble imagining a scenario where > you'd want to scatter xml:lang's randomly around an atom instance, so > maybe this is a handy simplification. I think that if we allow xml:lang then it should definitely be restricted. The current "xml:lang everywhere" situation is only simple to implement if you assume that your implementation stores all of it's data in an XML DOM. > Obviously, all bets are off once you get inside atom:content, right? Well, HTML and XHTML can include lang, and xml:lang according to their specs. They inherit the default language from their envelope. I think that is pretty well defined. -- Dave
