[uf-discuss] hAtom - ready for 0.1?

[Chris Casciano]

On Feb 27, 2006, at 10:59 AM, Robert Bachmann wrote:

> Tantek Çelik wrote:
>
>> Also I'd like to hear of when the hAtom2Atom.xslt might be updated so 
>> we can
>> try that on hAtom content and see how well it works.
> Revision 32 of hAtom2Atom.xslt<http://rbach.priv.at/hAtom2Atom/> should
> work, with these exceptions:
> - rel-tag handling
> - author handling
>
>> Aside from those two things, I personally see no reason not to 
>> declare hAtom
>> as version 0.1 and ready for folks to to use it in general.
> This needs some clarification:
>
>  * if the Entry Author is missing
>  ** find the [[algorithm-nearest-in-parent|Nearest In Parent]]
>  <code>&lt;address></code> element with class name <code>author</code>
>  ** otherwise the page is invalid hAtom
>
> Also note that the page "algorithm-nearest-in-parent" doesn't exists.
>

I still have some open questions about author handling in hatom myself 
but I didn't get the time I wanted this weekend to re-read the current 
docs.

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.


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)


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.

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.


The rest of the draft looks great to me.


[1] http://www.chunkysoup.net/
[2] http://microformats.org/wiki/hatom-examples#Transformation_2
[3] http://sky.placenamehere.com/
[4] http://microformats.org/wiki/hatom#Schema


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