[uf-discuss] hAtom and blog-post-* need some more work

Tantek Ç elik tantek at cs.stanford.edu
Sat Dec 31 19:42:26 PST 2005


On 12/31/05 11:53 AM, "David Janes -- BlogMatrix"
<davidjanes at blogmatrix.com> wrote:

> Dr.Ernie Prabhakar wrote:
>> Hi David,
>> 
>> On Dec 31, 2005, at 9:58 AM, David Janes -- BlogMatrix wrote:
>>> I don't even have the slightest idea how to respond to this. I've been
>>> working on hAtom since August (hardly a rush), constantly soliciting
>>> feedback, documenting progress and descions, recently providing code,
>>> and so forth.

First things first.

David, you have been doing an EXCELLENT job on hAtom.  I've largely stayed
out of the hAtom discussions precisely because you have been guiding them so
well. My input at this point is only to help improve a few details here and
there.  I want to make sure you understand that context.

>>> Now suddenly a new there's some new microformat
>>> principles -- not appearing on the Wiki in any obvious place or
>>> (particularly) the process page.

These are very much the principles of re-use.  And there have been some
notes on the process page about them.

However, you're right, the level of detail that I've outlined recently
hasn't been made clear on the wiki.

I will take as an action item the need to write up more detail on principles
and process around names and naming.


>> I certainly affirm your efforts to play by the rules and solicit input.
>> I think what Tantek may be reacting to was the perceived pressure to
>> "formalize" hAtom as an official microformat.  I think you've done a
>> fantastic job of documenting 'hAtom' per se, but there are valid
>> concerns about taking it to the next level.
> 
> Sure, and I've been consistently soliciting input on the nomenclature
> for a blog post microformat and changes have been made ... "bookmark",
> for example ... based on this input.

You absolutely have and have done a superb job of this - don't get me wrong.


> Furthermore, I have no issues with debating and or changing the
> nomenclature involved. For example, two or three days ago I explained
> the options that were available to us for the various elements, the
> precedence of HTML is using the word "title" or "heading" to mean
> "title" and why the word "summary" is particularly ill-suited in the the
> blog world for describing a title.

David, your ability to incorporate feedback and continue iterating is an
excellent example how someone who is spearheading a microformat should
behave.


> (Direct responses: 0)

A couple of minor pieces of feedback on this point.

A lot of collaborative efforts treat silence as consent.

While this is often a way to keep things moving quickly on implementations
and other development work, it's not necessarily the best for design, which
is what microformats essentially are.

To your credit David, you have explicitly *solicited* feedback on drafts,
changes, issues etc., so you have definitely done the right thing here.

What I want to point out is that the lack of response does not necessarily
imply approval.  It might (in general, not in this case), indicate
indifference.

Second, there we are using at least three different mediums of communication
to discuss microformats:

i. this list
ii. the irc channel irc:irc.freenode.net#microformats
iii. blog posts, either via tags "microformats", or perhaps the specific
microformat, e.g. "hAtom", or simply by mentioning those terms.

The fourth medium is of course the wiki, but that is more useful as a way to
capture state information (issues are both state and communication), than to
perform general communication.

Thus every microformat spec editor (and author/contributor) should pay
attention to all these communication channels, rather than expect a "direct
response" from any one.  Sometimes this is not possible, since not everyone
can monitor all channels.  Thus it is ok, to communicate these things on
more than one channel, e.g. by asking about an issue iin IRC, and then
adding it to the wiki, and then perhaps emailing a pointer to the issue on
the wiki.


> If there's a process, it can be followed by anyone, even if everyone
> here went away and was replaced by some other group of people.

Ideally yes.  We're certainly not at that level of detail in the process.

Now if that other group of people were cultural anthropologists, then they
would probably be able to figure out what we were doing, what direction we
were heading, and follow in our presumptive footsteps.



> If hAtom 
> breaks the process in any sort of non-trite way, I'll be the first to
> say that we should change it. But if we're just debating terminology,
> well let us debate that as opposed to a broad statement that I've been
> trumped by precedent, process and principles of the community.

Terminology is part of the *-brainstorming and spec drafting and *iteration*
phase.

One of our key principles is to draft something quickly (once the other
steps have been followed of course :), and then iterate rapidly based on
feedback.  This draft-quickly, iterate and evolve quickly is essential to
our rapid productivity.  The alternative is people getting stuck on their
first (or perhaps second) proposal due to the inertia of an implementation
or site or two.  And frankly, that's no good.


>>> I have no issue renaming elements in hAtom, as long as there's a
>>> microformats process that I'm actually following -- something that I've
>>> seriously attempt to do since the second week I've been on this list.
>>> I'm assuming the process is driven by documentation and discussion,
>>> and not by personality.
>> 
>> I think Tantek's principles are useful, and I agree they should be on
>> the wiki.  Are they? I'm not sure:

Part of it is written here:

http://microformats.org/wiki/process#Pages_to_consider_creating

But I will definitely admit I provide more explicit guidance on how to best
pick names and our overall vocabulary strategy for microformats.


> Well, have a look. By this is something that should be debated by the
> community -- if the principle is "one name/one meaning"

Certainly that.  The negatives of the alternatives are well established.

> and "first use, 
> first dibs", lets discuss the pros and cons of that.

Rather, the principles is reuse.  And the priority for us is to *first*
reuse from other microformats, and second to reuse from other well
established interoperable formats.  As the number of microformats grow,
we'll be reusing from those more and more often, because we'll inevitably
find that other standards have actually reinvented numerous wheels
(especially in the area of terminology).


> Strangely, I note that on the few discussions on namespaces (for
> example, [1]) the answer isn't "we don't need namespaces since we'll
> never reuse CSS classes to mean something different than a previous use".

That's *one* of the answers.

There is a key distinction here between the *root* class name (or names),
for a microformatted chunk of data, e.g. see:

 http://microformats.org/wiki/hcard-parsing#root_class_name

and the class names for the properties of that chunk are chosen based on
pre-existing microformat class names for properties, and "from pre-existing,
established, well-supported standards by reference". From:

 http://microformats.org/wiki/Template:semantic-xhtml-design-principles


>>>> Just because other standards keep inventing new terms for the same
>>>> thing, doesn't mean we should.
>>>> We should actively AVOID inventing new terms for the same thing, even if
>>>> those "new terms" come from other standards.
>> 
>> Thanks for all your efforts.

Yes, everyone in the microformats community is very thankful for your
efforts on hAtom David.  I think one of things we realize is that hAtom has
*incredible* potential, and so we're even more self-conscious about getting
it "right".


> No sweat. Well, actually, quite a bit of sweat -- which is why it's
> nicer to hear "we should be doing this differently" two months in rather
> than 4.

You are absolutely correct David.  With the rapid iteration of feedback,
issues, specification, and implementations, it is definitely the time to
bring up any outstanding issues about hAtom, to try using it on our own
blogs, and to report back how it works (or doesn't work).

We need to be our own best and harshest critics so that when we declare
hAtom ready for the "outside world", we already know exactly where all the
"soft points" are, and can provide good guidance.

I for one am working on a rewrite of my blog markup for January (though I
don't know if I will finish it in the next 5 hours :), based on hAtom.

The key here is to be up front with folks.

Please give hAtom a try and keep in mind that it will almost certainly
change, as can any of the "Exploratory discussions" or "Drafts" may.  If
that scares you, and you prefer stability before testing the waters, then
consider waiting a month (or two at most), and in the mean time, try out the
"Specifications" for now.

Thanks,

Tantek



More information about the microformats-discuss mailing list