[microformats-discuss] xFolk 0.4

[Tantek Ç elik]

On 7/11/05 5:18 AM, "Bud Gibson" <bud at thecommunityengine.com> wrote:

> On Jul 11, 2005, at 2:56, Tantek Çelik wrote:
> 
>> This also means that microformat spec authors MUST be up front
>> about the
>> iterative and evolutionary nature of this process, and thus we have
>> the
>> wording about a "work in progress" on the various microformat specs
>> that are
>> still be iterated on, *including* xFolk.
> 
> And I think we are doing just this with xFolk.  You'll note that this
> iteration brought to the fore the idea of adding the <img> element to
> the spec which seems like it should happen.  Sounds like rapid
> iteration to me.

Yes.

> I am less thrilled by the idea of changing attribute values.

Why?

> Only  
> infrequently is there a real value-add from that.


If it benefits usability, and human authoring, that is sufficient benefit.

Both of those trump implementations.  Humans first, machines
(implementations) second.


> People all have  
> their view on what an attribute value should be.

True.


> If you changed  every time, you would have as many attribute values
> as potential implementers.

That's a bit of a reductio ad absurdum Bud.  Nothing from this discussion
suggests changing a class name "every time".

And yes, there *MUST* be a good reason to change the name, REGARDLESS of
whether there are implementations or not.

But if there is a good reason, the name MUST be changed, REGARDLESS of
whether there are implementations or not.  That is also part of the
iteration/evolution.  For "compatibility" with past implementations or
content, earlier names may be kept in "deprecated" form.  You may find that
with how fast both specs and implementations iterate, that you can drop the
deprecated forms after a few iterations.


> So, the bottom line for right now is this:
> 
> 1.  The image element is going to come into a soon to be updated
> element of the spec.  Assume you can use it now with the same
> semantics as the <a> element.

Great.


> 2.  Eran, let me suggest that you and I chat in real time about the
> comment issue.  Usually, there is some html representation of the
> content as well as the RSS feed, and it might help to consider that.
> What would help here is a detailed use case.  We could get on IRC
> late in the day today or we could make another attempt by email.

I tend to agree with your earlier comment that RelTag already handles this
on its own.  There is no need to "reinvent" this with xfolk.  In fact, why
use something with more structure (xfolk) to represent a tagged comment (AKA
blog post) when something with less structure (RelTag) will do just fine?


> 3.  I think we agree that the "taggedlink" issue can be tabled (left
> as is) for now.  Something that I would find compelling is the idea
> that there is already a lot of usage, perhaps in a related community
> around another value.

I think the naming discussion is a good one and should continue.

One thing most technology folks are very bad at (not directed at you Bud),
is naming things understandably from a *users* point of view.  Usually they
name things understandably from a the programmer/implementer's point of
view, with the reasoning (especially with formats, and markup languages),
that the user will "never need to deal with it".

This is the majority view among technical people, and they are wrong.

One of the reasons HTML has succeeded so well is that the tag and attribute
names are (for the most part) fairly well named in terms of easily
understanding what they mean immediately.

"taggedLink" is a good example (my only nit being the camelCase - that's a
programmerism which IMHO has no place in names of tags/attributes/values for
user authoring, that's a longer discussion. suffice it to say, we chose all
lowercase URLs on the wiki for a reason (or several)).

taggedLink is fairly obvious what it means.

With the addition of images, what to do?

1. change to a new name for both links and images
2. keep taggedLink (perhaps rename to taggedlink) pick a new name just for
images

(1) keeps the spec "simplest".  The challenge is perhaps it becomes too
abstract.  RDF has the notion of "about" which many folk have difficulty
"grokking", perhaps because it is too abstract.

Would "tagged" be sufficient?

(2) you could have taggedimage, but when do you stop?  what if I use an
<object> to embed an audio file?  should that be taggedaudio?


BTW, Eran, your question of are you tagging the link or the thing at the end
of the link is a bit of an academic discussion.  For all intents and
purposes, the link *is* the thing at the end of the link.  If it helps,
consider the link the closes thing you have to a "proxy" for the thing at
the end of the link.  So yes, of course you are tagging the thing at the end
of the link.  The link is merely a reference/representation of it.


Thanks,

Tantek

P.S. Perhaps we need to start a wiki page on good naming conventions in
general, not just for URLs on the wiki.