[uf-discuss] Tentative proposal for "What's New" listings
brian suda
brian.suda at gmail.com
Tue Sep 26 13:13:25 PDT 2006
Stephen Paul Weber wrote:
>> If you see "../biblio/BirdLife/1983-0506-42.htm" on a page on the web,
>> it can have only one meaning, in the context in which you're seeing, it.
>
> Hmm... you may have convinced me, although I'm not sure how to go
> about this. So far the converter has been assuming that the hAtom was
> structured according to feed design rules (ie, only use absolute
> URLs), because that's what I do. I should probably look at adding
> some code to detect <a> tags with relative URLs though...
--- i'm not sure what the underlying code you are using is, but in the
hg.microformats.org there is a pretty mature XSLT to build and absolute
href. The other option, is that ATOM uses the XML:BASE attribute, so if
you could look for a <base> or <html xml:base> in the HTML and use that
in the conversion?
>> >> >Also, last time I checked RSS 2.0 required a full datestamp in that
>> >> >format for pubDate... nothing else should be legal
>> >>
>> >> That's annoying. If true, we should recognise that in the hAtom spec.
>> >
>> >Why? It's 100% irrelevant to microformats.
>>
>> Not if the hAtom spec says you can do something, which then leads to
>> unexpected, or even bizarre, results.
>
> I have finally figured out what you were talking about. The erroneous
> data was part of the bug in the date processor. The full timestamp is
> still there, but it now is properly representative of your data :)
again, not sure your underlying code, but i have been burned (plenty of
times) by date processing in XSLT (there is no built in date-time
functions) so i have split out the datetime.xsl and that should/can be
pulled into any other XSLT to process dates. It's not prefect but the
more people who use it, the more bugs we will find and fix.
-brian
More information about the microformats-discuss
mailing list