>The converter currently blindly uses the permalink value as GUID, if
>you use the same permalink twice in your hAtom you get this error.
Is that wise? Using the same link twice is allowed, isn't it?
This is a converter, not a standardiser. It assumes that your hAtom
is equivalent to legal RSS. my stdRSS tool (on the same site) DOES
generate GUIDs, I just never bothered with it in the converter. Since
you seem interested, however, I will definately look into copying over
some of that code :)
>>title should not contain HTML: " (6
>> occurrences)
>> Friends" section of our links page.
>
>The title is drawn directly from entry-title. This is not actually
>invalid RSS, it's just something they don't reccomend, but if you want
>it changed, change your hAtom.
By "change my hAtom", what do you mean? Surely you're not suggesting I
replace my escaped ampersands, with invalid ampersand characters?
Since there will be other people who use escaped entities, wouldn't it
be better for you, to deal with them by "unescaping" them?
I am suggesting that since XHTML is disreccomended in RSS <title> AND
in ATOM title tags that it may not be wise to have it in the
entry-title (ie, using the " character there instead of " would
be perfectly legal and solve the problem, the escaped ampersand is my
code escaping out your HTML entities, which the validator then finds
bad because there should be no enitities in a <title>).
>> line 389, column 3: item should contain a guid element
>
>Again, GUID is blindly drawn from permalink. No permalink, no GUID.
>This again is not invalid, as the results say, only disreccomended.
Again, is that wise? You could always use the URL of the source page
(+date-time) if no linking URL is present.
See above, I'll look at it.
>> This feed is valid, but may cause problems for some users. We
>> recommend fixing these problems.
>
>Again, none of these are actual invalidities
No, but I thought you'd want to know of them anyway (be generous in what
you receive strict in what you send...)
:)
>> line 74, column 17: description should not contain relative URL
>> references: ../biblio/BirdLife/1983-0506-42.htm" rel="bookmark"
>> title="letter in Bird Life magazine
>
>This is in your code... nor is it invalid, just not perfect.
Hey, who are you calling an imperfect coder! ;-)
> Not sure
>if making this an absolute URL (since it's escaped HTML) is really the
>converter's job
Whose then?
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...
>> line 100, column 46: Implausible date: Wed, 31 Dec 1969 23:59:59
>> +0000 (8 occurrences)
>
>This is probably because you use a different date format in your hAtom
>(Y-m-d) instead of the full hAtom-reccomended datestamp
>(Y-m-D\TH:i:sP).
Tath's not my reading of teh spec:
<http://microformats.org/wiki/hatom#Entry_Updated>
which says:
use the datetime-design-pattern to encode
then in turn:
<http://microformats.org/wiki/datetime-design-pattern>
says:
add a title attribute to the abbr element with the machine
readable ISO8601 datetime or date as the value
and, according to Wikipedia:
<http://en.wikipedia.org/wiki/ISO_8601#Years>
the format "yyyy-mm-dd" is allowable.
Ah, well, whatever the case may be, I did finally find a minor bug in
the date processor, so this should be fixed now.
Nonetheless, Sage is now showing some very odd results (do you see that,
or shall I "flickr" a screenshot?)
screenshot, I don't have Sage installed anymore, haven't for awhile
>> >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 :)
--
- Stephen Paul Weber, Amateur Writer
<http://www.awriterz.org>
MSN/GTalk/Jabber: [EMAIL PROTECTED]
ICQ/AIM: 103332966
NSA: [EMAIL PROTECTED]
BLOG: http://singpolyma-tech.blogspot.com/
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
