[uf-discuss] hAtom - ready for 0.1?

[Chris Casciano]

On Feb 27, 2006, at 4:42 PM, David Janes -- BlogMatrix wrote:

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

Within the semantics of ADDRESS this makes sense, but I guess I just 
don't see it working out in practice. Between the very regular cases of 
a single person 'blog' or an anonymous corporate news type feed 
regularly having no author in individual entries and the lack of 
flexibility of the ADDRESS element in practice (either because its lack 
of flexibility in nesting or because its overly strict meaning) I just 
can't see this being implementable by authors in a lot of cases.

> Chris Casciano wrote:
>
>> 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.

But when there just *ISN'T* going to be data the right thing isn't to 
fake it or try and make do anyway. It doesn't matter if the result is 4 
entries in my address book with nothing but "Chris" or just 1 so I 
don't think this is a tools issue at all. ALL you have is a nickname so 
why try to make it into more then that?

In an informal group blog setting there may be 4 cards with 4 different 
nicknames and no other data. There could be 4 names with a link to a 
page on the immediate site that may not be considered part of their 
contact info either (or only tangentially) and may or may not help 
access real information. So again, why try to make it more then it is 
or consumable in contexts where it doesn't apply.

This is clearly part an hcard issue and a broader how do you tie all 
these partial definitions of things together issue, but those big 
problems aside, the fact that the current hatom definitions prohibit me 
from implementing them on a few different sites with any satisfactory 
solutions to either the junk data problem or the reliance using an html 
element incorrectly (or redoing portions of sites or layouts) to 
properly conform to hatom is the immediate 0.1 problem in search of a 
solution.



-- 
[ Chris Casciano ]
[ chris at placenamehere.com ] [ http://placenamehere.com ]