I've just made a change in our implementation that in the following case...

  <content type="xhtml" xml:lang="en" xml:base="foo/">
    <div xml:lang="fr" xml:base="bar">Oui!</div>
  </content>

Content.getLanguage() will return "fr"
Content.getBaseUri() will return "foo/bar"

The other possible attributes are still available via a Div interface,
but in the default case, things just sort of work themselves out.

- James

Antone Roundy wrote:
> 
> On Jun 28, 2006, at 3:10 PM, Robert Sayre wrote:
>> The content in the entries below should be handled the same way:
>>
>> <entry xml:lang="en" xml:base="http://example.com/foo/";>
>>       ...
>>       <content type="xhtml">
>>               <xhtml:div xml:lang="fr" xml:base="http://example.com/
>> feu/"><xhtml:a href="axe.html">axe</xhtml:a></xhtml:div>
>>       </content>
>> </entry>
>>
>> <entry xml:lang="en" xml:base="http://example.com/foo/";>
>>       ...
>>       <content type="xhtml" xml:lang="fr" xml:base="http://example.com/
>> feu/">
>>               <xhtml:div ><xhtml:a
>> href="axe.html">axe</xhtml:a></xhtml:div>
>>       </content>
>> </entry>
> 
> Of course the end result of both should be identical.  Is that what you
> mean by "should be handled the same way"?  The question is, if the
> xhtml:div is stripped by the library before handing it off to the app,
> how is the app going to get the attributes that were on the div?  Is the
> library going to push those values down into the content or act as if
> they were on the atom:content element (or something similar to that)?
> 
> BTW, it just occurred to me that pushing them down into the content
> won't work.  Here's an example where that would fail:
> 
> <entry xml:lang="en">
>       ...
>       <content type="xhtml">
>               <xhtml:div xml:lang="fr">Oui!</xhtml:div>
>       </content>
> </entry>
> 
> Notice that there are no elements inside the xhtml:div for xml:lang to
> be attached to (and even if there were any, any text appearing outside
> of them would not have the correct xml:lang attached to it).
> 
> So it looks like the options (both of a which a single library could
> support, of course) are:
> 
> * Strip the div, but provide a way to get the attributes that were on it
> or
> * Leave the div
> 
> 

Reply via email to