[whatwg] microformats incompatible with WebApps 1.0 ?

[Mike Schinkel]

Ian Hickson wrote:
> It isn't clear to me that this is true. I believe this is one 
> of the reasons we are having difficulties with this 
> conversation -- we're starting from different initial assumptions.

Well, isn't it almost always that case on mailing list discussions?  Meaning
that what one person adamantly views as critical the other people thinks to
be irrelevant?  ;)

> Your use of the term "microformat" seems very loose. A 
> microformat isn't just anything that uses keywords in HTML's 
> extension attributes; a microformat is a format that has gone 
> through the very rigorous process of research, design, and 
> public study that Microformats.org documents. The entire 
> concept of a vendor-specific microformat is an oxymoron, for instance.

First, I find it ironic that on one hand you state microformats are require
a rigorous process yet on the other hand when people have asked for a
general purpose extension mechanism, you've pointed them to microformats as
their answer... (do I actually need to dig up references to your prior
responses, such as when you responded to Elias from IBM?)

BTW, on uf-discuss (do you lurk on it?) when people say "I want a
microformat that does 'x'" the people on the list often reply "We don't want
to make that a Microformat, but go ahead and do it; nothing stops you, just
don't call it a Microformat."

> We've managed to survive quite well without a "clearing 
> house" for ways of marking up metadata; 

That's because until recently almost nobody was actually doing it.  As use
of the "class" attribute increases, there is almost certainly going to be
more conflicting (lowercase) microformats released.

Actually, I don't care if you call it a Microformat or a
Fibb-Frotz-Foddoole, now that the idea is on the net with some examples of
how to do it, people who need to embed semantic metadata into HTML will get
the bright idea to do it the same way. I've already seen several people come
to uf-discuss who left frustrated by how closed and inflexible a process it
was.  I know because I am one of those people, as I have at least one
planned project that will revolve around metadata in HTML, but it won't use
"official" Microformats because uf-discuss already vetoed my first proposal
for reasons that apply to most of my needs. They just suggested I go off on
my own and create them anyway, and that I didn't need them to be offical
Microformats. But since the "class" is a scare resource (or "profile," or
whatever) that approach will result in conflicting microformats.

> I don't understand why we would need anything as formal 
> as you request. With a place for people to come together 
> and discuss proposals (the WHATWG wiki at the moment), 
> and with the natural market forces that human endeavours 
> like this end up involving, I don't really see that there's 
> anything to solve. At least not yet. 

So is the better approach to wait until the issue has created real
non-reversable problems and the web is even more Balkanized?  Can you say
XHTML and text/html? (I thought you could.)

BTW, I gave an actual example over on uf-discuss in reply to the above
suggestion, do you want me to dig up up and copy it here?

How about this as a simplier version of my proposal instead?:  

-- Keep Microformats to be what they are

-- Anywhere else people want to create "add-hoc" microformats using keyword
values in class/profile attributes say they SHOULD use the format of
"xxxx-yyyy" where "xxxx" is an ad-hoc context/namespace and "yyyy" is the
specific semantic markup, i.e.

	<span profile="webspec-editor">Ian Hickson</span>

-- If it's a multi-level sematic markup, they SHOULD disambiguate by using
"xxxx-yyyy-zzzz" where "zzzz" is the data element

	<div profile="webspec-info google-employee">
		<span profile="webspec-info-name">HTML5</span>		
		<span profile="editor google-employee-name">Ian
Hickson</span>	
	</div>

That's it. No registry. No process. Just some guidelines about how to use a
prefix. However, having the prefix will give the free market an architecture
around which to build the social mechanisms I proposed, when and if they are
needed.  Conflicts my still occur, but I'll bet the conflicts will be at
least an order of magnitude less likely.

As far as I can tell, this would have a small footprint in the spec. It
wouldn't be REQUIRED, and it wouldn't even need to be parsed by the HTML
parser. However, it would provide a disambiguation mechanism that frankly I
think would solve a huge future problem that will otherwise occur.

-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/

P.S. Already RDFa vcard conflicts with Microformat vcard.  Why not stop the
madness before it really starts?