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