[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.


More information about the microformats-discuss mailing list