* Antone Roundy <[EMAIL PROTECTED]> [2006-06-28 21:30]:
> Consider this:
> 
> <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>
> 
> Whether there's a problem depends on whether one requests the
> xml:base, xml:lang, or whatever for the atom:content element
> itself or for the CONTENT OF the atom:content element, in which
> case the library could return the values it got from the
> xhtml:div. Except in unusual cases like this, the result would
> be identical.

I can see your argument, but I find this too fine a distinction.
The `div` is part of the container when `type="xhtml"` as far as
I’m concerned. I’d just merge the information with that on the
`content` element and pretend there’s no difference. As far as
the feed’s *meaning* is concerned, there isn’t, after all.

> * give me the raw contents of the atom:content element
> * give me the contents of the atom:content element converted to
>   well-formed XHTML (whether it started as text, escaped tag
>   soup, or inline xhtml)
> 
> In the former case, keeping the div feels like the right thing
> to do -- the consuming app would have to know to remove it. In
> the latter case, removing the div from xhtml content feels
> like the right thing to do.

Yes, that sounds sane. “Give me the raw contents” would be
somehting only an Atom-aware API client would want to do, so it
is reasonable to expect that the client knows what to do with the
`div` when it finds that the content type was `xhtml`. Anyone who
just wants to use the data and doesn’t want to have to care about
how Atom works should just ask for XHTML and not care what it was
originally packaged as.

> ...now that I think about it, if the library always returns the
> xml:base which applies to the content of the element, that
> could cause trouble too:
> 
> <entry xml:lang="en" xml:base="http://example.com/";>
>       ...
>       <content type="xhtml">
>               <xhtml:div xml:lang="fr" xml:base="feu/"><xhtml:a
> href="axe.html">axe</xhtml:a></xhtml:div>
>       </content>
> </entry>
> 
> Here, if I get xml:base for the content of content, it will be
> "http://example.com/feu/";. Then, if I get the raw content of
> the element, strip the div, and apply xml:base myself, I'll
> erroneously use "http://example.com/feu/feu/"; as the base URI
> unless I know to ignore the xml:base attribute on the div.

I agree, but I don’t see how that’s at all to the point. Such an
API client is just buggy. If they ask for the raw `content`
content, then they should also ask for the `content` base URI,
not for the content’s base URI.

Guiding API clients to avoid such a mistake should be reasonably
easy by naming the methods appropriately, ie something like
`get_container_content` and `get_container_base` vs `get_content`
and `get_base`. (That the first pair of names is so long is fully
intentional… :-) )

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Reply via email to