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