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