[uf-discuss] hAtom - ready for 0.1?

[David Janes -- BlogMatrix]

Chris Casciano wrote:

> WRT the algorithm for finding an author outside of the entry (or hfeed 
> element) I'm still unsure about the quoted wording and as a result 
> specifically targeting the address element instead of alternatives used 
> elsewhere (class="author"). Are there implications to expanding that 
> rule that I'm not clear about? I've got the current revision of hatom 
> already implemented at ChunkySoup.net[1] but this item (and no current 
> parser to test with) is holding me up from being comfortable that I've 
> nailed it... because in the footer, outside of the hfeed element (which 
> I might end up removing now that its optional, but that's besides the 
> point) uses <p class="vcard author"> rather then an address based vcard 
> as there is other information in the sentence or two that that I don't 
> feel are  appropriate for an <address> element.

Here's how it works:
- Entry Authors MUST be marked with class name "author", no matter where 
they appear
- Entry Authors SHOULD (but not MUST) be in an <address> element

We had a meeting at Mashup Camp and that was the decision after some 
discussion. It all seems fairly reasonable.

Now, what do we do if there's no Entry Author in the Entry? We can't 
ignore this because Atom requires the Author. Here's what we came up with.

(1) Let P be Entry.parent
(2) Let A be a list of all the elements in P from an ordered depth-first 
traversal of P that satisfy:
     A.tagName = "ADDRESS"
     A.className contains "author"
     A is a valid hCard
(3) If len(A) > 0, A[0] is the author of the entry (END)
(4) Let P = P.parent
(5) If P != NULL, goto (2)

We're a little more strict (requiring ADDRESS) when we go outside of the 
Entry, because the HTML 4.01 semantics of ADDRESS make this make sense.

Note that there's no reference to the "hfeed" -- just work your way up 
till you find the author or not.

> My other question on author parsing goes to the simplification of author 
> inside of an entry... in earlier versions it was acceptable to not use a 
> vcard in the simple cases and simply have a string inside of an "author" 
> element. The older examples had just this[2]. To me this shorthand makes 
> sense if the information just isn't there to support a hcard because the 
> hcard could be picked up by other processes and used elsewhere. For 
> example, in an effort to get it out the door I used hatom on a new 
> textpattern theme[3] and marked up the author with the new accepted 
> hcard shorthand. The result of passing it though X2V's hcard-vcard 
> parser, then importing the output into OS X address book is I have 4 new 
> identical entries in my address book for the same "Chris" with a 
> nickname of "Chris"... pretty much a useless outcome if you ask me. 
> Allowing the case of no hcard as the old example does would eliminate 
> this noise. (yes, I know it would be much preferred to have more 
> complete author information on the page to connect Chris with some more 
> data, but in this particular case that wasn't to be for a variety of 
> reasons)

As per above, we had a discussion and felt the decision we made about 
requiring hCard made the most sense from a microformats and semantic 
sense. I feel your pain with regards to X2V and brought up a similar 
point, but it was felt that the spec should "do the right thing" and the 
tools should adapt.

> My other issue with the current 0.1 draft is a small one of readability 
> -- or rather understandability. The phrasing in the schema listing is 
> very awkward from an authoring POV. I understand why its written as 
> follows:
> 
> # updated. required using datetime-design-pattern.
> # published. optional using datetime-design-pattern.
> 
> But that doesn't really tell the whole picture of the relationship 
> between updated and published and a page author reading that bit might 
> erroneously think every entry has to contain an explicit value for 
> updated even if the CMS they're using doesn't have one, under normal 
> circumstances.

This is simply a summary and is following the pattern from hReview. The 
meat is in the following sections.

> 
> I don't know what the best way to phrase it so that its clear that if 
> published is valued but there is no updated that updated then equals 
> published, (or that from an alternate angle that published is required 
> if updated doesn't exist) but the current presentation just isn't 
> something I'd want a person just looking at implementing hAtom to see.

It's a little ugly, but if they follow the SHOULDs and MUSTs, I think it 
will pretty well implement itself :-)

> 
> The rest of the draft looks great to me.

Cool!

Regards, etc...
David