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 _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
