Re: Development of uFs outside the current framework (was: microformats vs. semantic XHTML (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats))

[Siegfried Gipp]

Am Donnerstag, 14. Dezember 2006 20:41 schrieb Andy Mabbett:

> What if ...
many "what if" :) 

> Well, quite. And there's more than one.

Sure. And why not. And there are already publications out there which are 
quite old, published long before the term "microformats" was invented, and 
which nevertheless is a proposal for the same purpose: Encouraging semantic 
markup. I do remember a work of someone, iif i recall right, named "Randall 
Trigg", who already defined relation types in the nineties. Although his 
relations where not between persons, but between web documents. A very 
interesting work. I currently do not have the url, but googling for it should 
work.

Or think of the several effords for link relations regarding types 
like "next", "prev", "contents" and the like. Already the w3c suggested some. 
I've put together a crude page resuming those, plus some reference links: 
http://www.rorkvell.de/tech/stdnav

> >In this context, "microformats" may be considered to be something like
> >a "brand".
>
> Like hoover or biro..?

I don't know these :) Well, to make it clear, think of "semantic markup" 
as "cigarettes". Then "microformats" is something like "Marlboro". That's a 
brand. You can invent any cigarette type you want, but it will never be 
Marlboro, if not branded by that company.


Regards
Siegfried
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Mike Schinkel]

Scott Reynen wrote:
> This mirrors how natural language works.   
> Until there is some need for clarification, we assume everyone knows  
> what we mean.  Then there is a need for clarification, we clarify.   
> No one goes around defining every word before they use it, 
> and I don't think we can expect publishers to behave 
> differently with HTML symbols.  We could require profile 
> URIs, but that won't make anyone use them.  OI think only a 
> practical need for disambiguation will do that.

The analogy is flawed. Humans have intelligences to compensate when
presented with ambiguity. Machine (at least currently) do not.

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


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: URI profiles [was RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats]

[Andy Mabbett]

In message <[EMAIL PROTECTED]>,
Elias Torres <[EMAIL PROTECTED]> writes

>> >> 2) Rather than having a profile for each uF (and, presumably,
>> >> near-duplicate profiles for nested uFs such as geo or adr in hCard?) why
>> >> not have one over-arching profile for all microformats?
>> >>
>> >
>> >Funny you say that since it's one of the biggest misconception of
>> >Semantic Web ideas. That SW seeks to find a single ontology for all of
>> >the data in the world. bleech.
>>
>> Were I suggesting what you seem to think I'm suggesting, your "bleech"
>> would be appropriate.
>
>I'm glad we are in sync then :) What were you really suggesting?

One over-arching profile for all microformats.

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: URI profiles [was RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats]

[Elias Torres]

On 12/14/06, Andy Mabbett <[EMAIL PROTECTED]> wrote:

In message
<[EMAIL PROTECTED]>, Elias
Torres <[EMAIL PROTECTED]> writes

>> 2) Rather than having a profile for each uF (and, presumably,
>> near-duplicate profiles for nested uFs such as geo or adr in hCard?) why
>> not have one over-arching profile for all microformats?
>>
>
>Funny you say that since it's one of the biggest misconception of
>Semantic Web ideas. That SW seeks to find a single ontology for all of
>the data in the world. bleech.

Were I suggesting what you seem to think I'm suggesting, your "bleech"
would be appropriate.


I'm glad we are in sync then :) What were you really suggesting?




--
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: URI profiles [was RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats]

[Andy Mabbett]

In message
<[EMAIL PROTECTED]>, Elias
Torres <[EMAIL PROTECTED]> writes

>> 2) Rather than having a profile for each uF (and, presumably,
>> near-duplicate profiles for nested uFs such as geo or adr in hCard?) why
>> not have one over-arching profile for all microformats?
>>
>
>Funny you say that since it's one of the biggest misconception of
>Semantic Web ideas. That SW seeks to find a single ontology for all of
>the data in the world. bleech.

Were I suggesting what you seem to think I'm suggesting, your "bleech"
would be appropriate.


-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: URI profiles [was RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats]

[Elias Torres]

On 12/13/06, Andy Mabbett <[EMAIL PROTECTED]> wrote:

In message <[EMAIL PROTECTED]>, Joe Andrieu
<[EMAIL PROTECTED]> writes

>Which means that URI profiles are /effectively/ required if you want to
>be assured that standards-compliant parsers will pick them up your
>microformats.
>
>Yea!  I think profiles are great.  So, why not formalize the
>requirement?

1)  If profiles are mandatory (or implicitly required by p*rser
behaviour), what happens to people who cannot edit the "head" element
(blog or CMS users, for instance)?


Didn't somebody proposed here or at WHATWG to have profile added to
any element in HTML? Would that solve the problem and limit the scope
of the usage of  a specific microformat?



2) Rather than having a profile for each uF (and, presumably,
near-duplicate profiles for nested uFs such as geo or adr in hCard?) why
not have one over-arching profile for all microformats?



Funny you say that since it's one of the biggest misconception of
Semantic Web ideas. That SW seeks to find a single ontology for all of
the data in the world. bleech. I wouldn't want such a beast.


--
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Development of uFs outside the current framework (was: microformats vs. semantic XHTML (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats))

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Siegfried Gipp
<[EMAIL PROTECTED]> writes

>Take f.ex. one of my pages: http://www.rorkvell.de/tech/dc This is a
>page which aims to combine the ideas of microformats with the Dublin
>Core vocabulary. This is by definition _no_ microformat, since this did
>not go through any process other than my own thoughts. But it is
>semantic markup and it is somewhat similar to microformats, it even
>sports an XMDP profile. But still it is _no_ microformat.

What if it takes off, and is adopted by many publishers and parsers
(let's say they include the Dublin Core body, and Google, respectively),
with many millions of examples on-line.

Will it be a uF then?

If not, why not?

>To convert that to a microformat that proposal would have to go through
>the microformats process.

What if it when through that process, not on this mailing list & related
'wiki', but, say, those belonging to the Dublin Core body?

What if that happened, but the process was a little different? Say 5%
different? Or 10%? Or..?

What if many such "pseudo-uFs" did the same, past the point where those
developed "here" were less than the (sacred) 20% of those widely in use?

>Simply a matter of definition.

Well, quite. And there's more than one.

>In this context, "microformats" may be considered to be something like
>a "brand".

Like hoover or biro..?

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: URI profiles [was RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats]

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Joe Andrieu
<[EMAIL PROTECTED]> writes

>Which means that URI profiles are /effectively/ required if you want to
>be assured that standards-compliant parsers will pick them up your
>microformats.
>
>Yea!  I think profiles are great.  So, why not formalize the
>requirement?

1)  If profiles are mandatory (or implicitly required by p*rser
behaviour), what happens to people who cannot edit the "head" element
(blog or CMS users, for instance)?

2) Rather than having a profile for each uF (and, presumably,
near-duplicate profiles for nested uFs such as geo or adr in hCard?) why
not have one over-arching profile for all microformats?

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: URI profiles [was RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats]

[Scott Reynen]

On Dec 13, 2006, at 1:40 AM, Joe Andrieu wrote:


Making people use them is not the same as clarifying in a spec what
should be done, must be done, and what is optional.  If we are
specifying that parsers can ignore non-profiled semantic HTML that  
looks

like microformats, we are essentially saying parsers can ignore
non-profiled microformats, since you can't tell the difference. Which
means that URI profiles are /effectively/ required if you want to be
assured that standards-compliant parsers will pick them up your
microformats.

Yea!  I think profiles are great.  So, why not formalize the
requirement?


So profile URIs are described here:

http://microformats.org/wiki/profile-uris

where it says:

"it is ACCEPTED that each microformat should have a profile URI."

I agree it would help to make that more clear, but if you're  
suggesting we change that "should" to a "must," I'd ask you what  
practical benefit you expect publishers would gain from such a  
change.  We're trying to avoid solving hypothetical problems here,  
and I don't see a practical problem profile URIs solve yet, as I  
haven't noticed anyone using class="vcard" to designate their  
Valentine's Day cards or anything else other than hCard.  If you're  
interested in seeing wider adoption of profile URIs, I'd recommend  
work on filling in the XMDPs for every microformat, because it  
wouldn't make much sense to require publishers to point to profiles  
which don't exist.


Peace,
Scott

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: the term microformat and encouraging people to play (was Re:[uf-discuss] Comments from IBM/Lotus rep about Microformats)

[Siegfried Gipp]

Am Dienstag, 12. Dezember 2006 20:16 schrieb Tantek Çelik:

> "microformats" is the specific "brand" (your term) of semantic (X)HTML that
> follows the microformats principles and process.
>
> You could say that RDFa is another "brand" of semantic (X)HTML that follows
> its own principles.

Just to be complete: Simply to use the html elements for what they where 
designed for is at least the first step to semantic (x)html. Even more 
important than microformats and RDFa. If used properly, any single bit of 
html markup _is_ semantic markup.

And, last not least, the rdf and owl effords of the w3c is semantic web, too, 
although it has nothing to do with (x)html. But well, the web is not 
identical to (x)html!

regards
Siegfried

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

URI profiles [was RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats]

[Joe Andrieu]

Scott Reynen wrote:
> On Dec 12, 2006, at 1:38 PM, Joe Andrieu wrote:
> > As I understand it profile URIs are not required.
> >
> > If so, the parser cannot distinguish between wild semantic 
> HTML and an 
> > hCard.
> 
> Profile URIs are not required for publishers, but parsers are 
> free to  
> ignore HTML without profile URIs, and I think it's reasonable to  
> expect them to start doing that if name conflict becomes more than a  
> hypothetical problem.  This mirrors how natural language works.   
> Until there is some need for clarification, we assume everyone knows  
> what we mean.  Then there is a need for clarification, we clarify.   
> No one goes around defining every word before they use it, and I  
> don't think we can expect publishers to behave differently with HTML  
> symbols.  We could require profile URIs, but that won't make anyone  
> use them.  OI think only a practical need for disambiguation will do  
> that.

Making people use them is not the same as clarifying in a spec what
should be done, must be done, and what is optional.  If we are
specifying that parsers can ignore non-profiled semantic HTML that looks
like microformats, we are essentially saying parsers can ignore
non-profiled microformats, since you can't tell the difference. Which
means that URI profiles are /effectively/ required if you want to be
assured that standards-compliant parsers will pick them up your
microformats.

Yea!  I think profiles are great.  So, why not formalize the
requirement?

If authors write non-compliant code (without the profile), *GASP*--who
would ever do that?--then they will have reason to understand why the
parsers ignore it. Just like if they write non-compliant HTML, they can
understand why it doesn't work. (Ahem, we'll ignore the issue of
non-compliant browsers).

However, without the profile requirement, authors have no reason to
expect that parsers won't pick up their "standards-compliant"
microformats.

100% compliant code should work with 100% compliant parsers. That seems
self-evident. Does it make sense to allow compliant parsers to ignore
compliant microformats?

-j

--
Joe Andrieu
[EMAIL PROTECTED]
+1 (805) 705-8651


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Scott Reynen]

On Dec 12, 2006, at 1:38 PM, Joe Andrieu wrote:


brian suda wrote

It is possible for me to start creating a CSS style called
'vcard', but a parser would know that this is a style and not
semantics because of the lack of a profile URI. Eventually,
as microformats become more popular,  the profile URI is used
to disambiguate random styles with intended semantic values.


Brian,

As I understand it profile URIs are not required.

If so, the parser cannot distinguish between wild semantic HTML and an
hCard.


Profile URIs are not required for publishers, but parsers are free to  
ignore HTML without profile URIs, and I think it's reasonable to  
expect them to start doing that if name conflict becomes more than a  
hypothetical problem.  This mirrors how natural language works.   
Until there is some need for clarification, we assume everyone knows  
what we mean.  Then there is a need for clarification, we clarify.   
No one goes around defining every word before they use it, and I  
don't think we can expect publishers to behave differently with HTML  
symbols.  We could require profile URIs, but that won't make anyone  
use them.  OI think only a practical need for disambiguation will do  
that.


Peace,
Scott

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: microformats vs. semantic XHTML (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats)

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>A "microformat" is such because it is a use of semantic class names,
>etc. that IN PARTICULAR:
>
>1. Are designed according to microformat principles [1]
>
>2. Follow the microformats process [2]

Of all the definitions of microformats in circulation, including that on
the main uFs web page, I believe that I have yet to see one which makes
those stipulations.

>Without those, all you have is semantic XHTML.

That's one opinion.

Another, for example, would be that any set of classes (and rels, or
whatever), used by a number of people, with various parsers and
aggregators, and marked up examples in the wild, constitute a de facto
microformat.

The fact that the only such examples at present came about through the
current 'wiki'/ mailing list/ 'community' does not preclude it from
happening, elsewhere, in the future.

>I have on my to-do list to better document the principles, more
>thoroughly, etc., as well as update the process per what we have
>learned the past six months or so.

When you do, will the proposed changes be posted here or on the wiki,
for discussion by the 'community', or will they be, in effect, imposed?

>I will note that for now, much deeper explanations of the principles
>are actually presented in the numerous podcasts about microformats that
>have been published:
>
>http://microformats.org/wiki/podcasts
>
>I encourage everyone who has participated in this thread to listen to
>them.

Where are their text transcriptions?

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Joe Andrieu]

brian suda wrote
> It is possible for me to start creating a CSS style called 
> 'vcard', but a parser would know that this is a style and not 
> semantics because of the lack of a profile URI. Eventually, 
> as microformats become more popular,  the profile URI is used 
> to disambiguate random styles with intended semantic values.

Brian,

As I understand it profile URIs are not required.

If so, the parser cannot distinguish between wild semantic HTML and an
hCard.

Or did I miss a change somehwere?

-j

--
Joe Andrieu
[EMAIL PROTECTED]
+1 (805) 705-8651


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: microformats vs. semantic XHTML (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats)

[Tantek Çelik]

On 12/12/06 11:19 AM, "Siegfried Gipp" <[EMAIL PROTECTED]> wrote:

> Am Dienstag, 12. Dezember 2006 17:17 schrieb Tantek Çelik:
> 
 lowercase microformats = unofficial semantic markup embedded in HTML
 uppercase microformats = "Official" Microformat
> 
> There is no such thing as "lowercase microformats". I think that came from the
> socalled "lowercase semantic web" vs. the "uppercase semantic web". The first
> is the grassroots movement we all know as microformats, which is not highly
> official and, most of all, does take a small step approach to semantic web,
> i.e. not defining a new file format, just adding to an existing format. The
> socalled "uppercase semantic web" on the other hand is the rdf and owl effort
> of the w3c, which offers much more, but is hell complicated and defines two
> completely new file formats.

Well said Siegfried.  It's important to remember that bit of history.

Thanks,

Tantek


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: microformats vs. semantic XHTML (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats)

[Siegfried Gipp]

Am Dienstag, 12. Dezember 2006 17:17 schrieb Tantek Çelik:

> >> lowercase microformats = unofficial semantic markup embedded in HTML
> >> uppercase microformats = "Official" Microformat

There is no such thing as "lowercase microformats". I think that came from the 
socalled "lowercase semantic web" vs. the "uppercase semantic web". The first 
is the grassroots movement we all know as microformats, which is not highly 
official and, most of all, does take a small step approach to semantic web, 
i.e. not defining a new file format, just adding to an existing format. The 
socalled "uppercase semantic web" on the other hand is the rdf and owl effort 
of the w3c, which offers much more, but is hell complicated and defines two 
completely new file formats.


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: the term microformat and encouraging people to play (was Re:[uf-discuss] Comments from IBM/Lotus rep about Microformats)

[Tantek Çelik]

On 12/12/06 10:40 AM, "S. Sriram" <[EMAIL PROTECTED]> wrote:

> What ufs(.org) has done is bring about a new category i.e. microformats
> into the collective mindspace, similar to Palm computers.
>
> Without a brand name to go with the category microformats,
> What will happen, is the Darwinian like splintering of categories into sub
> categories as in iPod, Zune, BlackBerry etc.

The term nor site microformats(.org) did not bring about a new category.

The category pre-existed: semantic (X)HTML.

"microformats" is the specific "brand" (your term) of semantic (X)HTML that
follows the microformats principles and process.

You could say that RDFa is another "brand" of semantic (X)HTML that follows
its own principles.

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: the term microformat and encouraging people to play (was Re:[uf-discuss] Comments from IBM/Lotus rep about Microformats)

[S. Sriram]

From: "Tantek Ç elik" <[EMAIL PROTECTED]>



the term "microformat" is simply too attractive.


It's interesting, because I couldn't have predicted this.  There was an 
even

earlier term "microcontent" which hinted at some of the same use cases,
which however, unfortunately didn't have a precise definition (nor any
definition really) that anyone used consistently (everyone used it to mean
their pet thing), and thus because its meaning was never clear, its usage
became quite diluted and worthless.

One of the reasons that I explicitly set about documenting the 
microformats
principles and process very early on in the evolution of microformats was 
to

avoid what happened with "microcontent".  This isn't finished.

We must continue to insist on a reasonably precise meaningful definition 
or
else the concept itself will become meaningless (or perhaps worse, 
subverted

by major vendors (though the names might be different this time around) as
was attempted with HTML).



What you have is a 'classic branding problem' i.e. using the category name 
for

the brand name, which is why there are discussions about lower/upper case M
mf.org v mf etc. A good book on the subject is Al Ries, Origin of Brands
where he outlines numerous examples to support the theory that people
think 'first' in 'need' second in 'categories' and than in brands which is 
why you need two names (category & brand)
(As in I'm thirsty (need), I want a beer(category), Give me a Bud 
Light(brand))

(and all of this happens in the space of a nanosecond)

some good examples of categories/brands are:
'energy drink' - red bull
'search' - google
'books online' - amazon

some bad examples of categories/brands are: [1]
'video warehouse' - Videowarehouse'
(Q.Which is the closest video warehouse? -A. Blockbuster of course) (read pg 
251)

'palm computers' - Palm
(I don't want to hear music on my laptop, but on a palmtop - so get an iPod)
(read pg 232, 233)

What ufs(.org) has done is bring about a new category i.e. microformats
into the collective mindspace, similar to Palm computers.

Without a brand name to go with the category microformats,
What will happen, is the Darwinian like splintering of categories into sub
categories as in iPod, Zune, BlackBerry etc.

[1] For those who don't have the book read pages 232/ 233 using Amazons's
search inside feature (keyword: palm computer) at
http://www.amazon.com/gp/reader/B00073HH7Y/ref=sib_dp_pt/103-5203347-8643834#

S. Sriram 


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

microformats vs. semantic XHTML (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats)

[Tantek Çelik]

Mike, Ben, a gentle reminder, please update the subject line when the
subject changes :)


On 12/11/06 8:45 PM, "Benjamin West" <[EMAIL PROTECTED]> wrote:

> On 12/11/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:
>> Benjamin West wrote:
>>> I'm not quite sure what you mean here.  Is there a difference
>>> between lowercase microformats and uppercase microformats?
>> 
>> lowercase microformats = unofficial semantic markup embedded in HTML
>> uppercase microformats = "Official" Microformat
>> 
> That's the first I've heard of this usage.

Same here.


> I think what I'm hearing
> (and agree with) is a need for a term that describes the product of
> semantic markup techniques in a general way. Lots of people are
> already doing this, and don't need any official body to bless them.

semantic XHTML (OR semantic HTML)

This is well-used well-adopted pre-existing term and there is no need to
invent a new term to mean the same thing.


> Microformats (any casing) would be a subset of these products that are
> blessed by pervasive use across the web.  I'm hesitant to pick out
> such a name, lest I choose badly (eg AJAX).  I'm happy to let the
> market pick that name (eg I don't think anyone should deliberately
> pick it out.), but at the same time, I'm hesitant to let the term
> microformats be applied to general applications of general techniques.

I'm frankly not ok with this.

This is one of the reasons why I have avoided capitalizing the term
"microformats" everywhere it is used.  There is no "capital" variant.  There
is just "microformats", as has been defined.

And just as "squares" are "quadrilaterals" with additional constraints,
microformats are semantic (X)HTML with additional constraints.

In particular, the difference between the specific semantic XHTML technique
that is 

"using semantic class names, ids, rel/rev values"

and a 

"microformat"

Is that *anyone* can make up semantic class names, id, rel/rev values, for
any reason in any way, and in fact, modern web designers and information
architects were doing so *long* before microformats was even coined as a
term.  Indeed, it was precisely this pre-existing behavior that inspired me
to first even dare to propose microformats as a refinement thereof.

A "microformat" is such because it is a use of semantic class names, etc.
that IN PARTICULAR:

1. Are designed according to microformat principles [1]

2. Follow the microformats process [2]


[1] http://microformats.org/wiki/microformats#the_microformats_principles

[2] http://microformats.org/wiki/process


Without those, all you have is semantic XHTML.


I have on my to-do list to better document the principles, more thoroughly,
etc., as well as update the process per what we have learned the past six
months or so.  Perhaps this holiday season I will have to spend some time
catching up on this given the extent of this thread.

 http://microformats.org/wiki/to-do#introduction_.2F_community

I will note that for now, much deeper explanations of the principles are
actually presented in the numerous podcasts about microformats that have
been published:

http://microformats.org/wiki/podcasts

I encourage everyone who has participated in this thread to listen to them.

Thanks,

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

the term microformat and encouraging people to play (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats)

[Tantek Çelik]

On 12/11/06 10:20 PM, "Håkon Wium Lie" <[EMAIL PROTECTED]> wrote:

Thanks for chiming in Håkon - your opinion is always appreciated.


> Also sprach Mike Schinkel:
> 
>>> I'm not quite sure what you mean here.  Is there a difference
>>> between lowercase microformats and uppercase microformats?
>> 
>> lowercase microformats = unofficial semantic markup embedded in HTML
>> uppercase microformats = "Official" Microformat
> 
> This makes sense to me. Preventing people from using the term
> "microformat" for their own set of class names is an uphill battle;

It is perhaps, but it is quite similar to the battle that W3C has fought
with use of the term "HTML", which, as we both know, was subverted by
various vendors etc. during the Browser Wars of the 1990s to mean *their*
variant of HTML.

Through the hard work of W3C, and advocate organizations like the Web
Standards Project (WaSP), that subversion was largely successfully fought
and overcome, and popular notion accepts that HTML is what W3C has defines
it to be (HTML 4.01, XHTML 1.0).

Just as with that uphill battle which was eventually won (except for a few
web designers stuck in 1990s-think who think HTML means "what works in IE",
ahem, *which* IE? :), it is worth fighting this battle to ensure that
microformats keeps its meaning above and beyond "semantic (X)HTML".

(Sidenote: ironically, W3C squandered this long fought for victory of what
is HTML with the sadness that is XHTML 2.0 which itself inspired/forced the
creation of WHATWG and HTML5 efforts, as well as microformats, but that's
another thread that an entire other mailing list is handling as you and I
both know.)


> the term "microformat" is simply too attractive.

It's interesting, because I couldn't have predicted this.  There was an even
earlier term "microcontent" which hinted at some of the same use cases,
which however, unfortunately didn't have a precise definition (nor any
definition really) that anyone used consistently (everyone used it to mean
their pet thing), and thus because its meaning was never clear, its usage
became quite diluted and worthless.

One of the reasons that I explicitly set about documenting the microformats
principles and process very early on in the evolution of microformats was to
avoid what happened with "microcontent".  This isn't finished.

We must continue to insist on a reasonably precise meaningful definition or
else the concept itself will become meaningless (or perhaps worse, subverted
by major vendors (though the names might be different this time around) as
was attempted with HTML).


> Besides, people
> should be encouraged to play.

Agreed - with some clear criticisms when they play for the wrong reasons, or
in a bad way.


For example there are people who invent their own "microformats" (as they
incorrectly call them) who can't even be bothered to publish valid XHTML.

If you cannot follow existing standards, how can you possibly expect
*anyone* to follow yours?


There are also people that are under the mistaken assumption that a
microformat they create is for their personal use.  I'm not naming names.

The point of a standard format is interoperability *between* *different*
parties.  I'll take that a step further and say that if at least *two* other
people (whom you are unrelated to etc.) are not interested in sharing
information with each other (i.e. not just you) via your "microformat"
proposal besides you, then stop - you have no microformat.

Just document (i.e. blog) your own personal use of semantic (X)HTML in the
hopes that if someone comes along later and wants to do something similar,
they *may* mimic your work.


> Most private sets will quickly die a
> natural death and do no harm. Those who survive in the wild deserve
> the capital M.

See previous email from me on "microformats vs. semantic XHTML" first.

I strongly encourage people to experiment and document their uses of
semantic XHTML.  In fact, if you read popular modern web designer blogs,
they have been doing this (not just *talking* about it) for *years*. [1]

If you want to participate in helping *others* interoperate (not just
yourself) and believe you have found a common publishing behavior on the web
that can benefit from greater interoperability, then by all means, follow
the microformats principles and process and develop a microformat to do so.

And those of you that *do* wish to develop microformats, I strongly
recommend you subscribe to and read popular modern web designer blogs, as
they are the ones who have the most experience with semantic XHTML (far more
than anyone in the XML/RDF communities), and they are who you should be
reading to understand where microformats came from and how to improve the
fidelity of your web publishing in general. [1]

Thanks,

Tantek

[1] In no particular order here are a few (and apologies in advance to those
I know I am forgetting this early Tuesday morning with this hastily created
list mostly off the top of my mind, and make sure your 

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[brian suda]

Mike Schinkel wrote:
> If it is not a scarce resource, please tell me what would happen if I
> decided to start marking up documents, as an example, using the class
> "directory" and "license", for purposes other than rel-directory and
> re-license?  How could my markup and those Microformats co-exist in the same
> HTML document?
>   
--- This hasn't been a problem yet, but we do have mechanisms to prevent
problems in this space.

It is possible for me to start creating a CSS style called 'vcard', but
a parser would know that this is a style and not semantics because of
the lack of a profile URI. Eventually, as microformats become more
popular,  the profile URI is used to disambiguate random styles with
intended semantic values.

So far this isn't a problem, and to save time and effort we are focusing
on the more important things. (IMHO) i would like to see more profile
attributes, but i am not too worried - we'll cross that bridge when we
need too, but there is a system in place to  solve these problems -
microformats are not "squatting" on terms.

-brian
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Håkon Wium Lie]

Also sprach Mike Schinkel:

 > > I'm not quite sure what you mean here.  Is there a difference 
 > > between lowercase microformats and uppercase microformats?
 > 
 > lowercase microformats = unofficial semantic markup embedded in HTML
 > uppercase microformats = "Official" Microformat

This makes sense to me. Preventing people from using the term
"microformat" for their own set of class names is an uphill battle;
the term "microformat" is simply too attractive. Besides, people
should be encouraged to play. Most private sets will quickly die a
natural death and do no harm. Those who survive in the wild deserve
the capital M.

-h&kon
  Håkon Wium Lie  CTO °þe®ª
[EMAIL PROTECTED]  http://people.opera.com/howcome



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Mike Schinkel]

Benjamin West wrote:
> That's the first I've heard of this usage.  I think what I'm 
> hearing (and agree with) is a need for a term that describes 
> the product of semantic markup techniques in a general way.  

It's my usage.  It seemed natural as I've heard the term uppercase/lowercase
used to distinguish between official and unofficial in other areas in the
past.

> Lots of people are already doing this, and don't need any 
> official body to bless them.

Agreed.  I just see the need to give those people a way to disambiguate
between themselves and Microformats. I've said the same here as well as on
WHATWG. But I'm not gaining any success to date. People are saying it is a
hypothetical problem while ignoring that I am saying it is an actual problem
in my usage.

> Microformats (any casing) would be a subset of these products 
> that are blessed by pervasive use across the web.  I'm 
> hesitant to pick out such a name, lest I choose badly (eg 
> AJAX).  I'm happy to let the market pick that name (eg I 
> don't think anyone should deliberately pick it out.), but at 
> the same time, I'm hesitant to let the term microformats be 
> applied to general applications of general techniques.
> 
> Does that reverberate at all with you, Mike, or anyone else?

That's exactly what I see going on here and discuss on WHATWG, so yes.  Ian
Hickson called it "Keywords in the HTML extension mechanism" and I reverted
to calling it "semantic markup embedded in HTML."  Maybe we could call it
SemMarE?  (yeah, I suck a making up names too. ;-)

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


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Ryan Cannon]

On Dec 11, 2006, at 11:43 PM, [EMAIL PROTECTED] wrote:

Brian Suda wrote:

Microformats are meant as building blocks and they should be
able to be using independantly and together...


If that is true, how can it be achieved without a disambiguation  
conventions
to keep official Microformats from conflicting with similar  
"techniques."


Or is it the view of the Microformat community that Microformats  
will keep
it's house clean and, because Microformats are the "anointed" ones  
that it

just "sucks to be the other guy?"


Since Microformats (capital-M) are based on research of current  
practice, I
think it's probably more helpful to think of techniques as proto- 
Microformats.


If the community is slow to develop a format that makes sense, we often
encourage authors to develop their own systems, which then can inform  
how a

format will function in the wild. This is where documentation and the
oft-belabored "process" becomes powerful. Although it can be annoying  
for
early-adopters and people who need solutions now, it creates strong  
formats

once the issues are solidified.

--
Ryan Cannon

Interactive Developer
MSI Student, School of Information
University of Michigan
http://RyanCannon.com


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Benjamin West]

On 12/11/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:

Benjamin West wrote:
> I'm not quite sure what you mean here.  Is there a difference
> between lowercase microformats and uppercase microformats?

lowercase microformats = unofficial semantic markup embedded in HTML
uppercase microformats = "Official" Microformat


That's the first I've heard of this usage.  I think what I'm hearing
(and agree with) is a need for a term that describes the product of
semantic markup techniques in a general way.  Lots of people are
already doing this, and don't need any official body to bless them.
Microformats (any casing) would be a subset of these products that are
blessed by pervasive use across the web.  I'm hesitant to pick out
such a name, lest I choose badly (eg AJAX).  I'm happy to let the
market pick that name (eg I don't think anyone should deliberately
pick it out.), but at the same time, I'm hesitant to let the term
microformats be applied to general applications of general techniques.

Does that reverberate at all with you, Mike, or anyone else?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Mike Schinkel]

Bruce D'Arcus wrote:
> In a world in which one CAN consider adding alternative 
> attributes (HTML 5, etc.), it makes no sense to me one would 
> simply say "no."

[I'm cross posting to uf-discuss and whatwg because Bruce's comment was made
on uf-discuss but I've made the same point on WHATWG.]

Bruce, I agree with you completely. But Ian Hickson has said that AFAHK that
there was no cry for additional attributes on the uf-discuss list, And Ian
also said he saw no need for them after I requested to get several
attributes added to the list of attributes applicable to all elements, i.e.
abbr, href, name, rel, rev, scope, size, src, type, and value.

I hadn't had the chance to ask the uf-discuss list about this, so now is a
perfect time.   What about adding additional standard attributes to all
elements.  Would it be helpful?

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


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Mike Schinkel]

Benjamin West wrote:
> I'm not quite sure what you mean here.  Is there a difference 
> between lowercase microformats and uppercase microformats?

lowercase microformats = unofficial semantic markup embedded in HTML
uppercase microformats = "Official" Microformat

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


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Mike Schinkel]

Brian Suda wrote:
> Microformats are meant as building blocks and they should be 
> able to be using independantly and together...

If that is true, how can it be achieved without a disambiguation conventions
to keep official Microformats from conflicting with similar "techniques."  

Or is it the view of the Microformat community that Microformats will keep
it's house clean and, because Microformats are the "anointed" ones that it
just "sucks to be the other guy?"

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

P.S. Actually it will just suck to be the guy who need to use both an
"official" Microformat and another one that is just a "technique?"

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Benjamin West]

The biggest problem is when two (lowercase) microformats get developed by
authors having no knowledge of the other, and then each microformats gets
adopted by different constituents.


I'm not quite sure what you mean here.  Is there a difference between
lowercase microformats and uppercase microformats?


Ben
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Mike Schinkel]

> Forgive me if I have missed something, but could a parser not 
> understand multiple formats if the HTML used was also 
> meaningful?  For example a blocklevel element (say a ) 
> could contain some content that was marked up with one 
> microformat, and another blocklevel element could contain 
> content marked up with another entirely different 
> microformat.  The fact that they shared the same page isn't a 
> problem.  A parser could easily identify child relationships 
> within the HTML and extrapolate.

A.) Possible, but that would require putting lots of intelligence into
parsers, which is generally considered A Bad Thing(tm) w.r.t. web
architecture goals.

B.) But if the two microformats markup similar content then probably not
possible.

> Granted this wouldn't be so easy if two microformats were 
> muddled together on the same page.  And if they were then 
> maybe there are two questions to ask.  1/ Is the microformat 
> in need of some additional elements?, and 2/ Is the author of 
> the page trying to do too much.
> could it be laid out differently?

The biggest problem is when two (lowercase) microformats get developed by
authors having no knowledge of the other, and then each microformats gets
adopted by different constituents. Finally, the content of a website is a
crossover for both constiuents creating a conflict between the microformats.

For example, lets say that two microformats one for business news and the
other for the car industry were independently created at roughly the same
time. Both includie markup for identifying a company; the subject of a news
story and the manufacturer of automobiles, respectively.  Since they are
both trying to mark up the same data, there's a good chance they will use
some of the same terminology but they may use it in conflicting ways.  

Now let's assume a site that provides auto news comes along, and ideally
needs to use both the news and the car industry microformats. Unfortuantely
they will have to choose only one because the two microformats conflict.  I
view creating an architecture that is likely to creat conflicts like this as
A Very Bad Thing(tm), especially when it would be so easy to resolve at this
point in Microformats' evolution.

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


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

false claim regarding relevance of topics on this list (was: [admin] Declaring end of thread (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats))

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>1. Parsing is OFF-TOPIC for microformats-discuss.

Furthermore, your assertion is not supported by:



A mailing list for general discussion of microformats

nor:



This is a public list for discussion of microformats.
Unmoderated, open subscription.

nor:



This is an open and public list for anyone interested in
microformats.

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

admins, prefix exceptions (was Re: [admin] Declaring end of thread (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats))

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>>> I am ending this thread of >50 messages now
>>
>> That's interesting - with what authority do you "declare end of thread".
>> Isn't this supposed to be a community, and isn't that or the community
>> to do?
>>
>> If there is an autocracy (or some other non-community based management
>> system) here, then surely it should be openly and honestly documented?
>
>I am an admin on this list/site as is Ryan King.

I know. That doesn't address my point.

>

Your refusal to address my concerns and answer questions on the
administration of *this list*, and its use by the community, is duly
noted.

>microformats>

"microformats" is not a sentient entity, it cannot have a view on such
matters.

>>> 3. Prefixing (e.g. "vcard-") has already been considered and rejected for
>>> microformats in general.  There have been deliberate exceptions made for one
>>> microformat (hAtom).  I'm not going to spend the time re-arguing this now -
>>> I have added an item to my to-do list on the wiki to better document this.
>>
>> Thank you for making clear that it's currently not (well) documented.
>>
>> Are we to understand also, that every decision, once made, even if
>> ill-documented, is irrevocable?
>
>No.
>
>
>> Or should we deduce that, if deliberate exceptions can be made in one
>> case, it is perfectly reasonable to suggest that deliberate exceptions
>> be made in another?
>
>Yes exceptions can be made but only with exceptionally good reasons.

So it's perfectly acceptable to make such a suggestion. Good.


-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

admins, prefix exceptions (was Re: [admin] Declaring end of thread (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats))

[Tantek Çelik]

On 12/9/06 12:11 PM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:

> In message <[EMAIL PROTECTED]>, Tantek Çelik
> <[EMAIL PROTECTED]> writes
> 
>> I am ending this thread of >50 messages now
> 
> That's interesting - with what authority do you "declare end of thread".
> Isn't this supposed to be a community, and isn't that or the community
> to do?
> 
> If there is an autocracy (or some other non-community based management
> system) here, then surely it should be openly and honestly documented?

I am an admin on this list/site as is Ryan King.








>> 3. Prefixing (e.g. "vcard-") has already been considered and rejected for
>> microformats in general.  There have been deliberate exceptions made for one
>> microformat (hAtom).  I'm not going to spend the time re-arguing this now -
>> I have added an item to my to-do list on the wiki to better document this.
> 
> Thank you for making clear that it's currently not (well) documented.
> 
> Are we to understand also, that every decision, once made, even if
> ill-documented, is irrevocable?

No.


> Or should we deduce that, if deliberate exceptions can be made in one
> case, it is perfectly reasonable to suggest that deliberate exceptions
> be made in another?

Yes exceptions can be made but only with exceptionally good reasons.

In the case of hAtom, you can read through the archives for the reasoning in
depth, but in summary: since we were reusing the semantics of the IETF Atom
standard, we very much wanted to reuse the vocabulary as well to minimize
confusion and mean precisely the same semantics as defined in the Atom RFC
4287, and thus a few of the hAtom properties appear to be prefixed
(entry-title, entry-content, entry-summary) in order to literally reuse
those terms from the RFC (title, content, summary).

Perhaps that would be a good hatom-faq entry.

Thanks,

Tantek


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[admin] Declaring end of thread (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats)

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>I am ending this thread of >50 messages now

That's interesting - with what authority do you "declare end of thread".
Isn't this supposed to be a community, and isn't that or the community
to do?

If there is an autocracy (or some other non-community based management
system) here, then surely it should be openly and honestly documented?

>Parsing is OFF-TOPIC for microformats-discuss.  Such discussions belong
>in microformats-dev.  See the mailing-lists page on the wiki where this has
>been documented for quite some time:
[...]
>And then - if you are not actually working on (i.e. coding) a parser, then
>please don't post until you are.

So, parsing should only be discussed by people who are actively writing
parsers? And someone proposing a microformat should not comment on how
it is intended to be parsed? And someone using uFs in their mark-up,
perhaps for the first time, should not ask questions about, nor comment
on, how they are being parsed?

If so, that would have made this conversation:




"illegal", resulting in the loss of the benefits gained form it.

It would also prohibit the discussion of most use-cases, and would
prohibit a proponent from answering questions about their proposed
microformat.

Also prohibited would be the reporting of bugs in parsers:




>Theoretical worries are not a priority.

They may not be *your* priority, but few inventions or advancements
could have been made, without some consideration of theoretical matters.

>2. Use real world examples for discussions.  Throughout this thread there
>have been numerous arguments based on strictly theoretical examples.
>
>The problem is we can waste ALL our time from now until forever
>discussing/worrying about theoretical examples and get nothing done.

Your implication, that all theoretical examples result in time wasting,
is unfounded.

>Theoretical examples are the equivalent to a DOS attack on actually getting
>things done.

Such hyperbole!

>3. Prefixing (e.g. "vcard-") has already been considered and rejected for
>microformats in general.  There have been deliberate exceptions made for one
>microformat (hAtom).  I'm not going to spend the time re-arguing this now -
>I have added an item to my to-do list on the wiki to better document this.

Thank you for making clear that it's currently not (well) documented.

Are we to understand also, that every decision, once made, even if
ill-documented, is irrevocable?

Or should we deduce that, if deliberate exceptions can be made in one
case, it is perfectly reasonable to suggest that deliberate exceptions
be made in another?

Put another way: how are we to resolve the clear inconsistency in your
third point?

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[admin] Declaring end of thread (was Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats)

[Tantek Çelik]

On 12/9/06 9:40 AM, "Scott Reynen" <[EMAIL PROTECTED]> wrote:

> On Dec 9, 2006, at 10:45 AM, Elias Torres wrote:
> 
>> However, more importantly, I need to find an
>> important enough instance of the so-called problem that needs us to
>> resolve the "general microformat(s)" case instead of hoping that if we
>> build it, they will come.
> 
> Exactly.  That's my primary concern with trying to solve this problem
> right now: building a solution around hypothetical publishing makes
> the solution more likely to fail when real publishing shows up.


This is the tip of the iceberg of the problems with this thread.

I am ending this thread of >50 messages now and am hoping to use it as both
a learning experience and example of what to avoid in order to improve the
signal to noise ratio on this list.


In no particular order:


1. Parsing is OFF-TOPIC for microformats-discuss.  Such discussions belong
in microformats-dev.  See the mailing-lists page on the wiki where this has
been documented for quite some time:





And then - if you are not actually working on (i.e. coding) a parser, then
please don't post until you are.  Theoretical worries are not a priority.


2. Use real world examples for discussions.  Throughout this thread there
have been numerous arguments based on strictly theoretical examples.

The problem is we can waste ALL our time from now until forever
discussing/worrying about theoretical examples and get nothing done.

Theoretical examples are the equivalent to a DOS attack on actually getting
things done.

I for one prefer to get things done and leave the theoretical examples for
the PhD authors of the future (no offense to PhD authors).

I've updated: http://microformats.org/wiki/mailing-lists#general_guidelines


3. Prefixing (e.g. "vcard-") has already been considered and rejected for
microformats in general.  There have been deliberate exceptions made for one
microformat (hAtom).  I'm not going to spend the time re-arguing this now -
I have added an item to my to-do list on the wiki to better document this.


4. Better "Subject" lines please.  When you fork a thread or focus on a
specific subject, please update the Subject in the email.  The vast majority
of the emails with subject "Comments from IBM/Lotus rep about Microformats)"
should have had some other subject line specific to the topic being
discussed.  This is already documented in the mailing list polices, which I
request everyone on this list please go re-read:

http://microformats.org/mailinglists-policies/


Thanks everyone - let's all work together to improve the signal-to-noise
ratio on this list.


Tantek




___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Scott Reynen]

On Dec 9, 2006, at 10:45 AM, Elias Torres wrote:


However, more importantly, I need to find an
important enough instance of the so-called problem that needs us to
resolve the "general microformat(s)" case instead of hoping that if we
build it, they will come.


Exactly.  That's my primary concern with trying to solve this problem  
right now: building a solution around hypothetical publishing makes  
the solution more likely to fail when real publishing shows up.  I  
think it would be good if more publishers were adding their own non- 
microformat semantics to their HTML to see how multiple experiments  
actually conflict and how those conflicts are most easily resolved  
before we formalize the process.


Peace,
Scott
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Re: Re: Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Brian Suda]

Thanks Elias for weighing in, i was getting abit worried that people
might have been "putting words in your mouth", it is glad to know you
are on the list to clear-up any potential confusions.

-brian

On 12/9/06, Elias Torres <[EMAIL PROTECTED]> wrote:

On 12/9/06, David Janes <[EMAIL PROTECTED]> wrote:
> On 12/9/06, Brian Suda <[EMAIL PROTECTED]> wrote:
>
[snip]
>
> We're not talking about the same thing but I think the case you're
> making here is pretty strong.
>
> The issue that I've been trying to solve in my mind (and I'm sure
> we're all on the same page here) is given an attribute A nested in
> micrformats M, N and P (from inner to outer), is "what does A belong
> to". If the answer is "all of them" then there seems to seems to be a
> potential conflict "consistent meaning" and "same meaning".
>

I'm trying to stay out of this because of I'm being consumed by other
commitments, but I'm really pleased to see a very healthy ongoing
conversation on the subject on this list. I think I really like the
way that David is stating the issue and am patiently hoping to see the
uf community taking this issue up further and watching for an outcome.

As an aside, I'm going to refocus my "semantic html" efforts from
worrying too much about the new attributes (e.g. RDFa: about,
property, etc) and worrying about mechanisms to resolve cases such as
the one posted by David. However, more importantly, I need to find an
important enough instance of the so-called problem that needs us to
resolve the "general microformat(s)" case instead of hoping that if we
build it, they will come.

-Elias
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss




--
brian suda
http://suda.co.uk
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Re: Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Elias Torres]

On 12/9/06, David Janes <[EMAIL PROTECTED]> wrote:

On 12/9/06, Brian Suda <[EMAIL PROTECTED]> wrote:


[snip]


We're not talking about the same thing but I think the case you're
making here is pretty strong.

The issue that I've been trying to solve in my mind (and I'm sure
we're all on the same page here) is given an attribute A nested in
micrformats M, N and P (from inner to outer), is "what does A belong
to". If the answer is "all of them" then there seems to seems to be a
potential conflict "consistent meaning" and "same meaning".



I'm trying to stay out of this because of I'm being consumed by other
commitments, but I'm really pleased to see a very healthy ongoing
conversation on the subject on this list. I think I really like the
way that David is stating the issue and am patiently hoping to see the
uf community taking this issue up further and watching for an outcome.

As an aside, I'm going to refocus my "semantic html" efforts from
worrying too much about the new attributes (e.g. RDFa: about,
property, etc) and worrying about mechanisms to resolve cases such as
the one posted by David. However, more importantly, I need to find an
important enough instance of the so-called problem that needs us to
resolve the "general microformat(s)" case instead of hoping that if we
build it, they will come.

-Elias
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Andy Mabbett]

In message
<[EMAIL PROTECTED]>, David
Janes <[EMAIL PROTECTED]> writes

>> >- never look for attributes inside BLOCKQUOTE or Q
>>
>> Why not?
>
>Because their definitions in the HTML spec [1] say that these are for
>pulling in data from elsewhere. From this one concludes that it's
>likely that this data is not necessarily going to be marked up in a
>way consistent with the current page.

Consider:

John Doe said: My new address will be 1, High Street,
Anytown

>> >- "unless explicitly defined to be otherwise"
>>
>> How would that be done?
>
>When writing a new microformat, one says "we look inside X Y and Z for
>A B and C"

And for existing uFs?

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Re: Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[David Janes]

On 12/9/06, Brian Suda <[EMAIL PROTECTED]> wrote:


i still think/feel that excluding embeded microformats inside other
microformats is a bad idea. The whole point of NOT having namespaces
is that the property values that we put into class/rel/rev have the
same consistent meaning across all formats and therefore SHOULD be
considered even when nested because it IS the same meaning.

As it stands, hCard does NOT have any rules for other microformats to
be nested inside of it... So if i were to do something like:

Brian Suda

  My Birthday
  Jan 1st


  



According to the "Never look inside other microformats when parsing
the outermost format" the "bday" value would never be picked-up by the
hCard parser. Also, if/when hFoobar came-out, if "to be a valid parser
you can't parse inside other formats" it would HAVE to know NOT to
parse inside hFooBar and how would it know not to do that unless, when
each new format is minted, all previous formats must also update? that
doesn't make sense to do.

I think that the other nested formats should be transparent and any
parser can look inside any other format - that's why we choose
property values that apply across the whole microformats spectrum.

Does that make sense? or are we both arguing (and agreeing) about the
same thing and just not realising it?


We're not talking about the same thing but I think the case you're
making here is pretty strong.

The issue that I've been trying to solve in my mind (and I'm sure
we're all on the same page here) is given an attribute A nested in
micrformats M, N and P (from inner to outer), is "what does A belong
to". If the answer is "all of them" then there seems to seems to be a
potential conflict "consistent meaning" and "same meaning".

Consider this nesting:



 ...
 8 December 2006

9 December 2006


In this example, I'm reusing "published" to mean to "the date of
publication of a microformatted object"; in one case, a blog entry and
in the other case, the page itself. This reuses the "published" class
from hAtom to a new microformat for describing the publication date of
the page (some research has happened on this in the past). If we ask
the parser for "give me the publication date of the page", then
obviously it has the sort out which to use. We could define a whole
new class for describing the publication date of the page, but then we
have multiple classes meaning more or less the same thing.

I don't have a happy solution for this and maybe it just comes down to
"work it out case by case". However, I potentially see it to be very
useful to reuse things like "fn" in nested microformats.

I'm still happy with the BLOCKQUOTE/Q rules.

Regards, etc...
David
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[David Janes]

>- never look for attributes inside BLOCKQUOTE or Q

Why not?


Because their definitions in the HTML spec [1] say that these are for
pulling in data from elsewhere. From this one concludes that it's
likely that this data is not necessarily going to be marked up in a
way consistent with the current page.



>- "unless explicitly defined to be otherwise"

How would that be done?


When writing a new microformat, one says "we look inside X Y and Z for
A B and C"

Regards, etc...

[1] http://www.w3.org/TR/REC-html40/struct/text.html#edef-BLOCKQUOTE
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Re: Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Brian Suda]

On 12/9/06, David Janes <[EMAIL PROTECTED]> wrote:

How would someone marking up a hCalendar with a hCard make the
location empty under those rules? The hCard is part of the hCalendar,
both as part of the spec [1] and implicitly because it's there.


You wrote earlier:
An "outer" microformat should
- never look for attributes inside nested microformats (particularly
hCard, hCalendar, hAtom and xFolk)

--- sorry, i took your: NEVER to mean NEVER-EVER and not NEVER, except
when it is part of the spec.

i still think/feel that excluding embeded microformats inside other
microformats is a bad idea. The whole point of NOT having namespaces
is that the property values that we put into class/rel/rev have the
same consistent meaning across all formats and therefore SHOULD be
considered even when nested because it IS the same meaning.

As it stands, hCard does NOT have any rules for other microformats to
be nested inside of it... So if i were to do something like:

Brian Suda

 My Birthday
 Jan 1st


 



According to the "Never look inside other microformats when parsing
the outermost format" the "bday" value would never be picked-up by the
hCard parser. Also, if/when hFoobar came-out, if "to be a valid parser
you can't parse inside other formats" it would HAVE to know NOT to
parse inside hFooBar and how would it know not to do that unless, when
each new format is minted, all previous formats must also update? that
doesn't make sense to do.

I think that the other nested formats should be transparent and any
parser can look inside any other format - that's why we choose
property values that apply across the whole microformats spectrum.

Does that make sense? or are we both arguing (and agreeing) about the
same thing and just not realising it?
-brian

--
brian suda
http://suda.co.uk
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[David Janes]

On 12/9/06, Brian Suda <[EMAIL PROTECTED]> wrote:

On 12/9/06, David Janes <[EMAIL PROTECTED]> wrote:
> My recent thinking has been that the following rules may work:
>
> An "outer" microformat should
> - never look for attributes inside nested microformats (particularly
> hCard, hCalendar, hAtom and xFolk)

--- i would also disagree with this because  then you creating
dependancies across ALL microformats, now and forever. If i create a
VALID hCard 1.0 parser... in 2 years when hFooBar hits the web, my
VALID 1.0 parser is no longer valid - other microformats could
obsolete existing standards. Microformats are meant as building blocks
and they should be able to be using independantly and together...
otherwise everytime someone marked-up an hCalendar with an hCard for
the venue, your hCalendar location would be empty. It's not a bug,
it's a feature.


How would someone marking up a hCalendar with a hCard make the
location empty under those rules? The hCard is part of the hCalendar,
both as part of the spec [1] and implicitly because it's there.

Ignoring the fact that it's part of the spec, my point still holds:
the _attributes_ of the hCard associate with the hCard and the hCard
as a _whole_ then is associated with the hCalendar.

Now, to understand your hFooBar example, consider two possibities:
hFooBar is embedded inside of (say) hCalendar, or hCalendar is used
inside of hFooBar.

If hFooBar is written to reuse class names from hCalendar, your 1.0
parser is going to be confused (interpret the microformat incorrectly)
in the embedded case _no matter what_. In the enclosing case (i.e.
hFooBar encloses hCalendar), it makes no difference because your 1.0
parser does not see hFooBar. If hFooBar does not reuse class names,
the your 1.0 parser is fine in both cases.

Regards, etc...

[1] http://microformats.org/wiki/hcalendar#More_Semantic_Equivalents
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Brian Suda]

On 12/9/06, David Janes <[EMAIL PROTECTED]> wrote:

My recent thinking has been that the following rules may work:

An "outer" microformat should
- never look for attributes inside nested microformats (particularly
hCard, hCalendar, hAtom and xFolk)


--- i would also disagree with this because  then you creating
dependancies across ALL microformats, now and forever. If i create a
VALID hCard 1.0 parser... in 2 years when hFooBar hits the web, my
VALID 1.0 parser is no longer valid - other microformats could
obsolete existing standards. Microformats are meant as building blocks
and they should be able to be using independantly and together...
otherwise everytime someone marked-up an hCalendar with an hCard for
the venue, your hCalendar location would be empty. It's not a bug,
it's a feature.

--
brian suda
http://suda.co.uk
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Andy Mabbett]

In message
<[EMAIL PROTECTED]>, David
Janes <[EMAIL PROTECTED]> writes

>My recent thinking has been that the following rules may work:
>
>An "outer" microformat should
>- never look for attributes inside nested microformats (particularly
>hCard, hCalendar, hAtom and xFolk)

You immediately hit problems with adr and geo inside hCard.

>- never look for attributes inside BLOCKQUOTE or Q

Why not?

>- "unless explicitly defined to be otherwise"

How would that be done?

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[David Janes]

The preceeding discussion about which class names apply to which
microformatted object ties into the conversation we were having nine
months ago (or so) about opacity; much is documented here [1].

My recent thinking has been that the following rules may work:

An "outer" microformat should
- never look for attributes inside nested microformats (particularly
hCard, hCalendar, hAtom and xFolk)
- never look for attributes inside BLOCKQUOTE or Q
- "unless explicitly defined to be otherwise"

This is still _theoretical_ and would need to be backed up by the
usual process related work, especially to see how it would impact
existing and proposed microformats. Note also my latest narrowing of
scope for an "item" microformat [2] which would make this less of an
open-ended statement.

Regards, etc...
David

[1] http://microformats.org/wiki/mfo-examples
[2] http://microformats.org/wiki/item
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Andy Mabbett]

In message <[EMAIL PROTECTED]>,
Tim Hodson <[EMAIL PROTECTED]> writes

>> Several possible solutions are available to us:
>>
>>1Declare that, if the attribute is inside a microformat (in this
>> case hCard), then it always applies to that uF, but not the
>> parent uF (in this case the citation)
>
>Surely 1 is the most logical?

Not necessarily

>The fact that the hcard title is NOT in
>the parent citation block would surely mean that I could make the
>sensible assumption that the title attribute for the hcard is NOT the
>same as the title attribute of the citation.  It would be up to me as
>author to clearly express what I meant by using correctly nesting
>tags.

There may be occasions when applying a class to a property in nested uF,
for use by both inner and outer uFs is sensible.

>>
>>2Uniquely name the first attribute as, say, class="book-title"
>> (compare to some of the proposed class names in the 'species'
>> proposal, which use this method to avoid other clashes).
>
>The citation may not be a book :)

Hence "say".

>>3Use an additional wrapper around the hCard on an additional
>> class on the hCard), to indicate that anything within that
>> wrapper does not apply to the parent.
>
>As for 3, this is already done in the example given.  The wrappers are
>named hcard and citation

Not so, because they don't currently carry that connotation.

>>
>> My preference is for option 2 - with hindsight, I would have named all
>> the classes in hCard as, say, "vcard-title".
>>
>>
>Naming all the classes with a prefix is unnecessary if you take the
>view that a microformat is a small set of attributes for distinct
>pieces of information.

Your latter consideration does not imply nor justify the former
conclusion.

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Tim Hodson]

On 09/12/06, Andy Mabbett <[EMAIL PROTECTED]> wrote:


 
Running an ISP for Idiots
 
 
   
Internet Expert [1]
   
  
 


There is a danger that "Internet Expert" might be recorded as the title
of the book (especially if the other title attribute is not present)

Several possible solutions are available to us:

   1Declare that, if the attribute is inside a microformat (in this
case hCard), then it always applies to that uF, but not the
parent uF (in this case the citation)


Surely 1 is the most logical?  The fact that the hcard title is NOT in
the parent citation block would surely mean that I could make the
sensible assumption that the title attribute for the hcard is NOT the
same as the title attribute of the citation.  It would be up to me as
author to clearly express what I meant by using correctly nesting
tags.



   2Uniquely name the first attribute as, say, class="book-title"
(compare to some of the proposed class names in the 'species'
proposal, which use this method to avoid other clashes).


The citation may not be a book :)



   3Use an additional wrapper around the hCard on an additional
class on the hCard), to indicate that anything within that
wrapper does not apply to the parent.


As for 3, this is already done in the example given.  The wrappers are
named hcard and citation, which brings us back to option 1.


My preference is for option 2 - with hindsight, I would have named all
the classes in hCard as, say, "vcard-title".



Naming all the classes with a prefix is unnecessary if you take the
view that a microformat is a small set of attributes for distinct
pieces of information.  As far as I know (and I haven't read every
microformat spec) there is almost always a root attribute which
defines what we are talking about - vcard, vevent, xoxo, the
exceptions are the rel/rev attributes which are defined using profiles
and can only sensibly have one meaning in a page.

best...

--
Tim Hodson
informationtakesover.co.uk
www.timhodson.co.uk
selfdescription.org
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Andy Mabbett]

In message
<[EMAIL PROTECTED]>, Tim
Hodson <[EMAIL PROTECTED]> writes

>A parser could easily identify child relationships within
>the HTML and extrapolate.
>
>Granted this wouldn't be so easy if two microformats were muddled
>together on the same page.

AIUI the concerns are about using the same class-name for two different
attributes. Say, the title of a book in a citation, vs. a job title in
an hCard.

Since a citation may include the author's hCard, it is thought that
there might be a conflict:


 
Running an ISP for Idiots
 
 
   
Internet Expert [1]
   
  
 


There is a danger that "Internet Expert" might be recorded as the title
of the book (especially if the other title attribute is not present)

Several possible solutions are available to us:

   1Declare that, if the attribute is inside a microformat (in this
case hCard), then it always applies to that uF, but not the
parent uF (in this case the citation)

   2Uniquely name the first attribute as, say, class="book-title"
(compare to some of the proposed class names in the 'species'
proposal, which use this method to avoid other clashes).

   3Use an additional wrapper around the hCard on an additional
class on the hCard), to indicate that anything within that
wrapper does not apply to the parent.

My preference is for option 2 - with hindsight, I would have named all
the classes in hCard as, say, "vcard-title".



[1] I actually knew of someone who has this as their job title ;-)

-- 
Andy Mabbett
*  Say "NO!" to compulsory ID Cards:  
*  Free Our Data:  
*  Are you using Microformats, yet:  ?
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Tim Hodson]

Forgive me if I have missed something, but could a parser not
understand multiple formats if the HTML used was also meaningful?  For
example a blocklevel element (say a ) could contain some content
that was marked up with one microformat, and another blocklevel
element could contain content marked up with another entirely
different microformat.  The fact that they shared the same page isn't
a problem.  A parser could easily identify child relationships within
the HTML and extrapolate.

Granted this wouldn't be so easy if two microformats were muddled
together on the same page.  And if they were then maybe there are two
questions to ask.  1/ Is the microformat in need of some additional
elements?, and 2/ Is the author of the page trying to do too much.
could it be laid out differently?

Simple is better afterall.

Tim

On 09/12/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:

Ryan King wrote:
> > How can I disambiguate when two Microformats collide?
> > Let me give a concrete example (one I will be working
> > on in the future):
>
> First profile wins. This had previously been clarified in
> HTML5, until Hixie decided to remove the profile attribute
> from HTML5.

Please tell me if I misunderstand, but I think that clearly identifies the
problem I've been trying to address: naming clashes on a scare resource.  If
what I think you said is correct, that would require someone to use one or
the other, but not both. That approach to web architecture is clearly not
acceptable, don't you agree?

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


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss




--
Tim Hodson
informationtakesover.co.uk
www.timhodson.co.uk
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Mike Schinkel]

Ryan King wrote:
> > How can I disambiguate when two Microformats collide?  
> > Let me give a concrete example (one I will be working 
> > on in the future):
> 
> First profile wins. This had previously been clarified in 
> HTML5, until Hixie decided to remove the profile attribute 
> from HTML5.

Please tell me if I misunderstand, but I think that clearly identifies the
problem I've been trying to address: naming clashes on a scare resource.  If
what I think you said is correct, that would require someone to use one or
the other, but not both. That approach to web architecture is clearly not
acceptable, don't you agree?

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


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: class="hack"? Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Dr. Ernie Prabhakar]

Hi Bruce,


My point, Ernie, is there's no obvious way to map it onto a model. I


Um, maybe I'm not quite understanding what you mean by "model". Are  
you saying that there's no way to create a generic parser that  
transforms the microformatted data into a normalized form?


What you may not realize (I didn't at first either) is that  
microformats.org is -- by *definition* -- optimizing for a world  
there are only a "handful" of discrete microformats.  Thus, there is  
no point in worrying about the general case; there are only special  
cases, and a relatively small number of those.


You may not believe or agree with that definition (not all of us do  
either :-), but that's the rules we play by here.  If you want a more  
generic approach, you might be happier with GRDDL.


Cheers,
-- Ernie P.

On Dec 8, 2006, at 2:11 PM, Bruce D'Arcus wrote:


On 12/8/06, Dr. Ernie Prabhakar <[EMAIL PROTECTED]> wrote:


On Dec 8, 2006, at 4:04 AM, Bruce D'Arcus wrote:
> Likewise, using class to indicate both properties and, um,  
class, is

> also a hack.

I think that's probably where we part company.   I suspect most of us
here consider the use of HTML "class" for semantic information fully
in line with the both the letter and spirit of the spec, and thus an
entirely natural usage.


My point, Ernie, is there's no obvious way to map it onto a model. I
don't think that's such a controversial thing to say. We've got tables
and columns (RDBMSes), resources and properties (RDF), objects and
attributes (oo). Class and ... ?

Bruce
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: class="hack"? Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Bruce D'Arcus]

On 12/8/06, Dr. Ernie Prabhakar <[EMAIL PROTECTED]> wrote:


On Dec 8, 2006, at 4:04 AM, Bruce D'Arcus wrote:
> Likewise, using class to indicate both properties and, um, class, is
> also a hack.

I think that's probably where we part company.   I suspect most of us
here consider the use of HTML "class" for semantic information fully
in line with the both the letter and spirit of the spec, and thus an
entirely natural usage.


My point, Ernie, is there's no obvious way to map it onto a model. I
don't think that's such a controversial thing to say. We've got tables
and columns (RDBMSes), resources and properties (RDF), objects and
attributes (oo). Class and ... ?

Bruce
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Ryan King]

On Dec 7, 2006, at 3:45 PM, Mike Schinkel wrote:

--- these values are not "reserved" across all of HTML. We
have a mechanism to prevent this, it is called Profile URIs,
if a parser comes across class="vcard" then the best way to
determine if this is a random CSS Style or a semantic value
is to see if there is a Profile URI that matched the XMDP of hCard.


Are you referring to this?
http://www.w3.org/TR/html401/struct/global.html#profiles

Is a Profile URI a well-known URI where I have to find semantics  
elsewhere
or if not what format is returned by the URI? (just trying to  
understand)


Somewhere in between the two– they preferable return an XMDP  
description of the microformat. XMDP is not formally descriptive  
enough to be able to automatically parse the microformat, you have  
the read the prose to understand all the constraints.



How can I disambiguate when two Microformats collide?  Let me give a
concrete example (one I will be working on in the future):


First profile wins. This had previously been clarified in HTML5,  
until Hixie decided to remove the profile attribute from HTML5.


-ryan



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Ryan King]

On Dec 8, 2006, at 4:04 AM, Bruce D'Arcus wrote:

Let's review:

Microformts are a clever set of conventions to reuse existing HTML
attributes to encode some sort of structured meaning.

However, using "title" to encode machine-readable content is pretty
much a hack. Title, after all, is really for human readable labels.


I agree, it's not the cleanest of possible solutions. It *is* a  
compromise. Find us something better and we'll switch.



Likewise, using class to indicate both properties and, um, class, is
also a hack.


I'm not sure how you can justify claiming this. You must have read a  
different HTML specification than I have, because in my reading,  
there are no limits on how the class attribute can be used in HTML.  
According to the spec, it's available  for "general processing by  
user agents". I've explained more fully before [http:// 
microformats.org/blog/2005/10/19/more-than-styling/].



These hacks are no doubt necessary and practical in the context of
current HTML and I really have no problem with it in that context, but
it's precseily why there can be no generic microformat parser.


You say that like it's a bad thing. Show me a generic parser that  
works on the scale of The Web. Even HTML parsers are not generic–  
browser vendors commonly have to vary their browser's behavior from  
site to site in order to deal with differences. At least the same  
microformat can be extracted from different sites in the same way  
(once you know how to parse the HTML :D).


-ryan
--
Ryan King
[EMAIL PROTECTED]




___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

class="hack"? Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Dr. Ernie Prabhakar]

Hi Bruce,

On Dec 8, 2006, at 4:04 AM, Bruce D'Arcus wrote:

Likewise, using class to indicate both properties and, um, class, is
also a hack.


I think that's probably where we part company.   I suspect most of us  
here consider the use of HTML "class" for semantic information fully  
in line with the both the letter and spirit of the spec, and thus an  
entirely natural usage.


If you consider *that* an unfortunate hack, then we're probably  
arguing from fundamentally different premises and unlikely to reach  
any sort of meaningful conclusion. :-)


Cheers,
-- Ernie P.

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Bruce D'Arcus]

On 12/7/06, Ryan King <[EMAIL PROTECTED]> wrote:

...


>> Also, I'm not sure how 'people not getting their pet properties' is a
>> problem specific to microformats.
>
> True. It doesn't mean it has to repeat the same mistake though. I
> would certainly hope the HTML 5 effort would be open minded about
> learning from all of the efforts in this space.

HTML 5 has profile URIs and the specification is much more clear as
to how they are to be used (thanks to Tantek bugging Hixie about
that). I think HTML 5's current extension methods (profiles, rel and
class) are sufficient.


Let's review:

Microformts are a clever set of conventions to reuse existing HTML
attributes to encode some sort of structured meaning.

However, using "title" to encode machine-readable content is pretty
much a hack. Title, after all, is really for human readable labels.

Likewise, using class to indicate both properties and, um, class, is
also a hack.

These hacks are no doubt necessary and practical in the context of
current HTML and I really have no problem with it in that context, but
it's precseily why there can be no generic microformat parser.

In a world in which one CAN consider adding alternative attributes
(HTML 5, etc.), it makes no sense to me one would simply say "no."

Bruce
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Mike Schinkel]

Scott Reynen wrote:
> The next question I expect is: what if you want to use both 
> the microformats.org rel-license and your own conflicting 
> rel-license in the same document?  Well, you can't.  

And that is exactly the problem.

> Just like in natural language, if you want to start using symbols 
> with meanings that conflict with the established standard, 
> you need to be prepared to establish a new standard meaning.  

And that is not good for the web.

> And the usefulness of your new meaning, rather than some 
> central authority, will determine whether or not people use 
> it in place of the alternative meaning.

So, are you saying it would have been better not to have had the W3C specify
HTTP 1.1 and HTML 4.01 and instead let market forces prevail?  

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





___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Mike Schinkel]

S. Sriram wrote:
> They would simply co-exist. Period

My only response to your comments is that I strongly disagree with you, but
as you appears you have a similar conviction it would be a waste of time to
debate it further.  

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


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Mike Schinkel]

> --- these values are not "reserved" across all of HTML. We 
> have a mechanism to prevent this, it is called Profile URIs, 
> if a parser comes across class="vcard" then the best way to 
> determine if this is a random CSS Style or a semantic value 
> is to see if there is a Profile URI that matched the XMDP of hCard.

Are you referring to this?
http://www.w3.org/TR/html401/struct/global.html#profiles

Is a Profile URI a well-known URI where I have to find semantics elsewhere
or if not what format is returned by the URI? (just trying to understand)

How can I disambiguate when two Microformats collide?  Let me give a
concrete example (one I will be working on in the future):

Looking at ADR, here is an example:


 665 3rd St.
 Suite 207
 San Francisco,
 CA
 94107
 U.S.A.


Now let's say I want to use something called "RegionData" where Regions are
heirarchical:


 
665 3rd St.; Suite 207
 
 San Francisco,
 CA
 94107
 U.S.A.


Now, someone needs to use both:


 
665 3rd St.
 Suite 207
 
 San
Francisco,
 CA

 94107
 U.S.A.


How do I disambiguate between region-data's "region" and vcard's "region?"
Assume I created my RegionData with no knowledge that vcard existed, because
unless there is a central clearing house to avoid name clashes, two
different groups will end up creating conflicting microformats with clashing
names.

> It is also only a hypothetical issue, so until this becomes a 
> real issue, we're not going to worry too much about it, but 
> we do have a system that solves this problem. So we aren't 
> "squatting" on any values.

Hypothetical issues sometimes have a way of "biting people in the ass,"
using a phrase Mark Baker recently said on the REST-discuss forum on another
topic. :)
However, this is not a hypothetical issue. A project I'm working on that I'm
not willing to go public with yet will make heavy use of microformats-like
markup, and I've already seen a lot of potential for collision such as the
one above, which is an example of a planned use.

But maybe Profile URIs can solve this.  Can you please explain how, using my
example?

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


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Brian Suda]

On 12/7/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:

If it is not a scarce resource, please tell me what would happen if I
decided to start marking up documents, as an example, using the class
"directory" and "license", for purposes other than rel-directory and
re-license?  How could my markup and those Microformats co-exist in the same
HTML document?


--- these values are not "reserved" across all of HTML. We have a
mechanism to prevent this, it is called Profile URIs, if a parser
comes across class="vcard" then the best way to determine if this is a
random CSS Style or a semantic value is to see if there is a Profile
URI that matched the XMDP of hCard.

(IMHO) i would like to see more profile URIs in use, but at the moment
this is not a real-world problem. We have many more important things
to deal with, so Profile URIs are a sort of "we'll cross this bridge
when we come to it".

It is also only a hypothetical issue, so until this becomes a real
issue, we're not going to worry too much about it, but we do have a
system that solves this problem. So we aren't "squatting" on any
values.

-brian

--
brian suda
http://suda.co.uk
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Scott Reynen]

On Dec 7, 2006, at 2:28 PM, Mike Schinkel wrote:


If it is not a scarce resource, please tell me what would happen if I
decided to start marking up documents, as an example, using the class
"directory" and "license", for purposes other than rel-directory and
re-license?


The classes wouldn't cause any problems, but if you mean the "rel"  
attribute, that would cause parsers to do confusing things with the  
data.  Then people would start complaining to the parser developers,  
and the parser developers would start ignoring those attributes  
unless they were accompanied by the appropriate profile headers.  And  
then publishers would start using the appropriate profile headers to  
disambiguate their microformats.  None of that is happening now  
because there's no (or very little) ambiguity now, so there's little  
incentive to pre-emptively disambiguate.  But if ambiguity ever  
becomes a real problem, there's a solution in profile headers ready  
to be used.


The next question I expect is: what if you want to use both the  
microformats.org rel-license and your own conflicting rel-license in  
the same document?  Well, you can't.  Just like in natural language,  
if you want to start using symbols with meanings that conflict with  
the established standard, you need to be prepared to establish a new  
standard meaning.  And the usefulness of your new meaning, rather  
than some central authority, will determine whether or not people use  
it in place of the alternative meaning.


Peace,
Scott

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[S. Sriram]

From: "Mike Schinkel" <[EMAIL PROTECTED]>

S. Sriram wrote:

This is not a scarce resource, people can
(and are) naming classes as they choose.
Any constraint happens at the parsing stage,
since microformat-aware parsers look for
specific class names etc. (see below)


If it is not a scarce resource, please tell me what would happen if I
decided to start marking up documents, as an example, using the class
"directory" and "license", for purposes other than rel-directory and
re-license?  How could my markup and those Microformats co-exist in the 
same

HTML document?



They would simply co-exist. Period.

Hypothetically, say the author uses rel-license
for some internal markup and has unwittingly cut/pasted in a
uf-snippet containing a rel-license tag. The consumer of this
microformat will now be presented with spurious/confusing
data.

How different is this from a web page (today) that contains a rel-license
entry which was not intended to be a microformat in the first place.
Not much. This too will lead to a spurious/confusing interpretation if 
consumed

as a microformat. But, is that not what ALL current usages of
this are and is that not how microformats even chooses these
terms by sifting through the way people actually use them.

In other words, just finding a markup on a page that resembles
a microformat 'does not necessarily mean that is is one'. This
is true today. The burden of interpretation is on the consumer
not the author.

Now, if the argument is that authors are 'constrained' in their
class naming freedom, and have to avoid the usage of rel-license
altogether (unless used as specifically noted by microformats.org)
since microformats have 'squatted' on it. The response is NO, you
are not constrained, as the burden of interpretation falls on the
consumer of the microformat and not its author.

As for multiple namespaces and a bureaucracy to govern that, it is
highly unlikely. What is more likely is a white/blacklisting mechanism
if spammers etc. begin wide use of it, much the same way blogs are
being white/blacklisted.

S. Sriram 


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[S. Sriram]

From: "Ryan King" <[EMAIL PROTECTED]>

On Dec 5, 2006, at 8:48 AM, S. Sriram wrote:

From: "Mike Schinkel" <[EMAIL PROTECTED]>

http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- 
December/00

8462.html

I wonder if his issues can be addressed?


How about a distributed parser-discovery service


What's wrong with GRDDL [http://www.w3.org/2004/01/rdxh/spec]?



Nothing. Except that in this case it  introduces yet another parsing burden 
on the

browser/renderer
i.e. from rdf/xml to JSON or other renderable format.

S. Sriram 


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Ryan King]

On Dec 7, 2006, at 12:29 PM, Bruce D'Arcus wrote:

On 12/7/06, Ryan King <[EMAIL PROTECTED]> wrote:

...


The RDF dream of having a generic parser and model has yet to win on
the open web. I'm more than happy to let the market decide whether
it's more value to have formats that are easy to publish, or those
that are easy to parse (I'm sure you can guess which side I'll take).


Why does this need to be an either/or choice?  Why must
ease-of-authoring trade-off generality here?


I'm not saying that it has to be, but that it appears to be so in  
practice. I've found that general purpose data formats are harder to  
author than specific ones. For example, HTML is more work than  
Markdown for the kinds of writing that Markdown allows. I tend to use  
Markdown pretty often because of that.



...


Also, I'm not sure how 'people not getting their pet properties' is a
problem specific to microformats.


True. It doesn't mean it has to repeat the same mistake though. I
would certainly hope the HTML 5 effort would be open minded about
learning from all of the efforts in this space.


HTML 5 has profile URIs and the specification is much more clear as  
to how they are to be used (thanks to Tantek bugging Hixie about  
that). I think HTML 5's current extension methods (profiles, rel and  
class) are sufficient.


-ryan
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Bruce D'Arcus]

On 12/7/06, Ryan King <[EMAIL PROTECTED]> wrote:

...


The RDF dream of having a generic parser and model has yet to win on
the open web. I'm more than happy to let the market decide whether
it's more value to have formats that are easy to publish, or those
that are easy to parse (I'm sure you can guess which side I'll take).


Why does this need to be an either/or choice?  Why must
ease-of-authoring trade-off generality here?

...


Also, I'm not sure how 'people not getting their pet properties' is a
problem specific to microformats.


True. It doesn't mean it has to repeat the same mistake though. I
would certainly hope the HTML 5 effort would be open minded about
learning from all of the efforts in this space.

Bruce
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Mike Schinkel]

S. Sriram wrote:
>> This is not a scarce resource, people can 
>> (and are) naming classes as they choose.
>> Any constraint happens at the parsing stage, 
>> since microformat-aware parsers look for 
>> specific class names etc. (see below) 

If it is not a scarce resource, please tell me what would happen if I
decided to start marking up documents, as an example, using the class
"directory" and "license", for purposes other than rel-directory and
re-license?  How could my markup and those Microformats co-exist in the same
HTML document?

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


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Mike Schinkel]

Roger L. Costello wrote:
>> Mike, you've raised some excellent concerns.  It fundamentally boils down
to an issue of interoperability.  If the Microformat's community splinters
and, say, multiple versions of hCard are created then we immediately have an
interoperability problem.  

I believe that what appears to be the vision for Microformats among the
group based on the majority of replies that either appear to be
authoritative or were definitely authoritative will end up frustrating
people who originally were enthused by the concept and cause them to go off
and create their own markup that is potentially incompatible and chaos will
ensue.

>> Tantek calls namespaces an enabler of stovepipes. 

I agree that XML namespaces are a nightmare.  But I think a much simpler
mechanism can achieve the same goal.

But rather than just complain and say there is a problem, I will instead
propose a simple solution.  What's needed is a single and "officially
recognized" clearing house for anything metadata tagged to HTML attributes.
Since the WHATWG already points to Microformats (in the generic sense) as
the solution for HTML extensibility, I believe Microformats.org could easily
be viewed as that central authority.  Without a clearinghouse that is
structured to allowing scale-up, we will ultimately see the use of tags on
classes fall into chaos and it will be far worse than the "serving XHTML as
text/html" problem that exists on the web today.  

Here are the steps I propose:

-- Microformats.org should become a clearing house for "official"
microformats using the structure below.
-- There would be three classes of Microformats: horizontal and
vertical/specific, and vendor.
-- Proposals for a class of "Vertical/specific" Microformats would
be reviewed by a committee and if approved be given a "context prefix," i.e.
"ubio-", "wine-", etc.
-- Proposals would only be turned down if there is already
another Microformat that does the same thing and can achieve the goals
needed of the proposers
-- Vendors could request and receive a "context prefix," i.e.
"ibm-", "goog-", "ms-", "yahoo-", "ebay-", etc.
-- "Horizontal" Microformats would still be created as today, but
ideally with a "uf-" prefix.
-- All these prefixes would be set up in a managed and machine
readable repository by Microformats.org (or IANA, if applicable.)
-- Create an online forums for discussion of each
"Vertical/specific" and "vendor" context prefix.
-- For each "Vertical/specific" Microformat, there would need to
have one member from the general Microformat community to oversee it to
ensure semantic/syntactic integrity.
-- Multi-element microformats would need the prefix, but enclosed
elements would not (see [1] below) except (see next item)
-- Exceptions would be when two conflicting Microformats
were used on the same data, then there would be a need to prefix all
elements (see [2] below)
-- Relax the draconian "visible only" aspect of Microformats to keep
people from splintering off who need non-visible metadata.

[1] 
http://tantek.com/";>Tantek Çelik
Technorati


[2] 
http://tantek.com/";>Tantek Çelik
Technorati


The above is required because of Microformats use of a scarce resource,
similar to how the DNS service is needed to ensure that there is only one
website representing the domain microformats.org. If the above (or something
else that also addresses the issues) was agreed and adopted, Microformats
would become a powerful force of good structured data on the Internet. If
not, Microformats and similar competing efforts will end up causing far less
value on the Internet than chaos, and will eventually be dropped by web
publishers.

Respectfully,

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

P.S. I came to Microformats thinking the above was logically be how it would
have been implemented, but I quickly become disillusioned after learning how
there was not vision associated with seeing it scale to meet the needs of
the entire internet community. I now feel that without reform the best
Microformats can ultimately achieve is not be too terribly damaging.  I hope
that others can come to see my logic.



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Ryan King]

On Dec 6, 2006, at 5:45 AM, Bruce D'Arcus wrote:

On 12/5/06, Scott Reynen <[EMAIL PROTECTED]> wrote:

...


In HTML or JSON, new formats need new parsers, which must be written
by someone.


Exactly. The point is if you have a generic model you have a  
generic parser.



Elias is coming from an RDF background, and microformats
simply aren't RDF, and they never will be.  And that's a good thing.
If what you want is RDF, just use RDF.


The issue isn't really microformats vs. RDF (except as RDF provides a
model), but microformats vs. RDFa.

Both microformats and RDFa are addressing the exact same use cases and
requirements (augmenting visible content with structured data).

RDFa includes namespacing, the lack of which is already a problem in
microformats (witness hCite and the serious awkwardness that title
will be indicate using fn), and which will grow over time as more and
more people want to mark up their content.

Moreover, the need to write dedicate code for each new microformat
will also present serious scalability problems.


Yes, in order to parse and consume microformats, you'll have to have  
code that knows about those formats.


The RDF dream of having a generic parser and model has yet to win on  
the open web. I'm more than happy to let the market decide whether  
it's more value to have formats that are easy to publish, or those  
that are easy to parse (I'm sure you can guess which side I'll take).



Finally, that there's no model at the heart of microformats with clear
extension rules means that the vaunted social process here is a mess.
It's all centralized, and people get frustrated when their pet
property isn't included because they know what that means: the tools
written for the blessed microformats won't see them.


I agree that there are cases where we can be more organized and I'm  
more than willing to implement new tools or processes to do this.


Also, I'm not sure how 'people not getting their pet properties' is a  
problem specific to microformats.


With other technologies, like XML, the person who didn't get their  
pet property included in a given namespace could create their own  
namespace and advocate that people make use of it. Still, I don't  
believe that it changes the reality that tools won't know what to do  
with it unless *someone* writes some code. I don't think the  
situation is any worse in microformats, and it may in fact be better.  
If your 'pet property' doesn't make it into a microformat, you can  
still publish it and advocate that others use it. If consumers of  
said microformat decide that the data is valuable, they'll parse it  
and if enough people do this, then it'll get added to the microformat.


-ryan

--
Ryan King
[EMAIL PROTECTED]



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Ryan King]

On Dec 5, 2006, at 8:48 AM, S. Sriram wrote:

From: "Mike Schinkel" <[EMAIL PROTECTED]>

http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- 
December/00

8462.html

I wonder if his issues can be addressed?


How about a distributed parser-discovery service


What's wrong with GRDDL [http://www.w3.org/2004/01/rdxh/spec]?

-ryan 
___

microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Ryan King]

On Dec 5, 2006, at 5:07 AM, Bruce D'Arcus wrote:

On 12/5/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:

For those on this list who are not following [whatwg], here is an
interesting thread about inability to use Microformats:

http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- 
December/00

8462.html

I wonder if his issues can be addressed?


I think the only way it can be addressed is with some effort to
harmonize microformats and RDFa, which is not going to happen for what
seem to me largely political reasons.


I'd say it's much more like 'philosophical differences'.

-ryan


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[S. Sriram]

From: "Mike Schinkel" <[EMAIL PROTECTED]>

because Microformats squat on a scare resource (names in classes.)




This is not a scarce resource, people can (and are) naming classes as they 
choose.
Any constraint happens at the parsing stage, since microformat-aware parsers 
look

for specific class names etc. (see below)

From: "Costello, Roger L." <[EMAIL PROTECTED]>

down to an issue of interoperability.  If the Microformat's community
splinters and, say, multiple versions of hCard are created then we
immediately have an interoperability problem.



No, this is merely a rendering problem. From the microformat hCard parsing
page [1]


forward compatible parsing
When parsing the contents of an hCard, any unrecognized class names must be 
ignored. >Similarly, unrecognized values for hCard properties must also be 
ignored.


So, if  one wanted to extend hCard with additional fields i.e. blog-url,
activity-url they are free to do so. Generic
parsers/renders *will not barf* and simply discard the superset.
Specific parsers/renderes would be needed however to accomodate this.

In other words, the constraints imposed by microformats.org should not 
effect

others. They can leverage off of existing microforamtted-objects, build
their own alongwith corresponding parsers/renderes and in browsers that
only understand standard microformats, they most likely will degrade
gracefully and the subset be parseable/renderable

[1] http://microformats.org/wiki/hcard-parsing
S. Sriram 


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Costello, Roger L.]

Mike Schinkel wrote:

> The core problem is no strategies have been adopted to avoid naming
> collisions, and to avoid having the whole concept self destruct from
it's
> own weight of complexity. People who want to contribute but can't
because
> the centralized Microformat community is not interested will go off
and
> create their own and names start clashing, we'll just be left with
one big
> mess. 

> Most of the Microformat community seems to want to keep Microformats
a tight
> knit club focused on a small number of use cases that reviews and
approves
> everything, declining things they don't like, but I think there is
really an
> obligation to the Internet at large to address how to scale the
process
> because Microformats squat on a scare resource (names in classes.) 

Mike, you've raised some excellent concerns.  It fundamentally boils
down to an issue of interoperability.  If the Microformat's community
splinters and, say, multiple versions of hCard are created then we
immediately have an interoperability problem.  

Tantek calls namespaces an enabler of stovepipes. 

I hope that Tantek will weigh in on this issue.  In the past he has
addressed this issue, but a regular repeat is very worthwhile I
believe.  It strikes at the very heart of the Microformat's philosophy,
and the very heart of achieving interoperability on the Web.

/Roger

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Benjamin West]

Benjamin West wrote:
>> Talk of general microformats doesn't make sense.  Talk of microformats as
technique also does not make sense.
If that is true, then having Microformat Design Patterns[1] doesn't make
sense.  Which is it?


I'm not sure what you mean.  A design pattern is a technique, which is
separate from what a microformat is.  A microformat is an application
of several techniques to a specific end.  When some techniques prove
successful, they become patterns.  The techniques are means for
generalized extensions, while a microformat is a specific application
of those techniques for a specific extension.  Microformats exhibit
emergent characteristics from wide usage on the web; this
characteristic means that these formats only exist because they have
already scaled  --even before they were borne.  So I guess I'm not
sure what the concern for scaling is.

Ben
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Mike Schinkel]

Bruce D'Arcus wrote:
>> RDFa includes namespacing, the lack of which is already a problem in
microformats (witness hCite and the serious awkwardness that title will be
indicate using fn), and which will grow over time as more and more people
want to mark up their content.
>> Moreover, the need to write dedicate code for each new microformat will
also present serious scalability problems.
>> Finally, that there's no model at the heart of microformats with clear
extension rules means that the vaunted social process here is a mess.
>> It's all centralized, and people get frustrated when their pet property
isn't included because they know what that means: the tools written for the
blessed microformats won't see them.

I agree with your comments.

Whereas I think XML namespaces are too difficult for widespread adoption in
HTML markup, I think the lack of any similar scope mechanism for
Microformats and the resistance of some in the Microformat to prepare
Microformats for scaling in usage and application mean that Microformats may
end up being remembered as "a good idea at the time" but quite possibly not
in use several years out. 

Scott Reynen wrote:
>> I think it's just a limited goal of solving specific problems as simply
as possible.  If people want to solve general problems without the
constraints of keeping it simple for publishers, I'd say they should do that
somewhere else.

I think you are creating a false dichotomy. I do agree that RDF is too
difficult, but I don't think addressing the issues in another way would
necessarily sacrifice ease of use.

David Janes wrote:
>> The best part about microformats (IMHO) is not the class and rel and abbr
stuff, but the fact that it deliberately constrains itself to real problems
that people are actually having.

But only those real problems, as Bruce pointed out, that "conform to some
limited set of terms that only get agreed to through some tortuous process
of which the vast majority of people couldn't be bothered."  

Benjamin West wrote:
>> Talk of general microformats doesn't make sense.  Talk of microformats as
technique also does not make sense.  
If that is true, then having Microformat Design Patterns[1] doesn't make
sense.  Which is it?

The core problem is no strategies have been adopted to avoid naming
collisions, and to avoid having the whole concept self destruct from it's
own weight of complexity. People who want to contribute but can't because
the centralized Microformat community is not interested will go off and
create their own and names start clashing, we'll just be left with one big
mess. 

Most of the Microformat community seems to want to keep Microformats a tight
knit club focused on a small number of use cases that reviews and approves
everything, declining things they don't like, but I think there is really an
obligation to the Internet at large to address how to scale the process
because Microformats squat on a scare resource (names in classes.) 

With great power comes great responsibility; Microformats has a
responsibility to the web at large to ensure Microformats can scale, but all
I've seen is resistence to even consider that (which is one of the reason's
I've been quiet lately.)

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

[1] http://microformats.org/wiki/Main_Page#Design_Patterns

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Benjamin West]

Some clarification:

Isn't "microformats" more than one microformat?  And what is a
microformat?  I thought a microformat was a specific collection of
defined names and structure defined by a rigorous process of market
research intended to consider pervasive use of semantic html in order
to increase data fidelity of HTML-borne data widely distributed on the
web.

When people mention "microformats" they often are referring to "the
use of semantic html to increase data fidelity."  This is extremely
confusing because a microformat, or Microformat, is something more
than any use of semantic html, it's a specific use to represent
specific data.  That is to say that the word "microformats" does not
refer to a technique of data representation.  Microformats are not a
general extension mechanism, and such language is very confusing, and
harmful to discussion.

The general extension mechanism is to publish data using the best
semantic techniques available, currently via class,rel,profile...  The
fact that microformats use these means doesn't somehow turn
microformats into a technique for doing so.  Vendors, authors, or
anyone, can use the same techniques to raise proprietary data fidelity
in HTML, but that doesn't turn them into a microformat.  Data formats
using these techniques achieve candidacy as a microformat when their
use is widespread.

Talk of general microformats doesn't make sense.  Talk of microformats
as technique also does not make sense.  Talk of microformats as a
group makes sense, but only when it refers to more than one actual
microformat. When applied to people, "Microformateers" is probably
better.



Ryan,
Thanks for helping to clear this up on the whatwg list, to some
degree.  Do we need to be more protective of our vocabulary?


-Ben

P.S.
The definition I've given is what I understand microformats to be.
AFAIK, there is no official definition, which may be contributing to
the splintering of our vocabulary and mindshare.  If I'm wrong I'm
sure someone will correct me.
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[David Janes]

Why should RDFa get to mooch of the reputation that microformats has
developed over the last 24 months? That reputation was developed by a
lot of hard work by a lot of people (and really hard work by a few).

What has RDFa brought to the table?

Like microformats, RDFa wants to carry inline machine readable data
with human readable data.  Beyond this? It models data in a way that
no one uses, to solve problems no one has, in a way that no one can
find a use for [1][2].

The best part about microformats (IMHO) is not the class and rel and
abbr stuff, but the fact that it deliberately constrains itself to
real problems that people are actually having.

Regards, etc...
David

[1] http://www.google.com/search?hl=en&q=rdf+applications&btnG=Google+Search
[2] http://programmableweb.com/apis

On 12/6/06, S. Sriram <[EMAIL PROTECTED]> wrote:


That's right, I think that what RDFa does is hint at realising the
potential that microformats (in general) offer (to institutions),
which 'microformats.org'
with its inherent (and probably valid) limitations stops short of.

Maybe, thinking of RDFa as microformats (in general) and
microformats.org/microformats as microfortmatted-objects (in particular)
might
help understand this relationship better.


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Bruce D'Arcus]

On 12/6/06, Scott Reynen <[EMAIL PROTECTED]> wrote:

...


I don't think the issue is "vs." at all.  The two approaches solve
different problems, are interoperable, and collectively improve the
semantics of the web.  It's all good.  ...


Yes, I certainly agree with this.


> Both microformats and RDFa are addressing the exact same use cases and
> requirements (augmenting visible content with structured data).

I don't think the use cases and requirements are the same at all, and
I hope they never are or we're just doing redundant work here.
RDFa's use cases include a generic semantic model.  Microformats do
not.  Microformats have a requirement of making publishing as easy as
possible to maximize adoption.  RDFa does not share this
requirement.  These are two different efforts that will lose
usefulness if merged into one.


OK, I'll grant that the requirements do differ a little (ease-of-use
vs. generality), but if you look through the RDFa examples, they're
all the same kinds of examples. They have more commonality than not it
seems to me.

My problem is that as near as I can tell, this conversation just
doesn't happen. Every time the subject is broached (usually by
developers who don't see much difference between the efforts), Tantak
shuts it down (which I expect to happen soon to this thread).

...


 From my perspective, all of these attempts to make microformats more
generalizable are sort of like telling people who are doing math on
their fingers that they should stop because that won't scale.  That's
true, but they don't want it to scale right now.  They just want to
solve a simple problem using familiar tools.  When they get to
calculus, they'll pull out the calculator.  I don't want to see
microformats turned into a calculator while there are plenty of
finger-math problems left to be solved.


:-)

The nice things about metaphors are that they are simple. It's also
their problem; they obscure far more than they illuminate often.

The problem of metadata is not math after all, and in the real
practical world out there, people want to describe what they want o
describe; not to conform to some limited set of terms that only get
agreed to through some tortuous process of which the vast majority of
people couldn't be bothered.

Bruce
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[S. Sriram]

From: "Scott Reynen" <[EMAIL PROTECTED]>


So while it might be comforting to dismiss RDFa and "it's not our
problem", I don't think it's good strategy.


A good strategy toward what end?  I think Elias has a problem that 
microformats are not intended to solve.  What he wants to do is have  a 
generic semantic model that anyone can use with any type of data,  and put 
it in HTML.  What microformats are intended to do is provide  specific 
semantic models, not just /in/ HTML, but using the familiar  tools of HTML 
as much as possible.




That's right, I think that what RDFa does is hint at realising the
potential that microformats (in general) offer (to institutions),
which 'microformats.org'
with its inherent (and probably valid) limitations stops short of.

Maybe, thinking of RDFa as microformats (in general) and
microformats.org/microformats as microfortmatted-objects (in particular) 
might

help understand this relationship better.

S. Sriram

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Scott Reynen]

On Dec 6, 2006, at 7:45 AM, Bruce D'Arcus wrote:


On 12/5/06, Scott Reynen <[EMAIL PROTECTED]> wrote:


In HTML or JSON, new formats need new parsers, which must be written
by someone.


Exactly. The point is if you have a generic model you have a  
generic parser.


Right.  HTML doesn't have a generic semantic model.  JSON doesn't  
either, nor does XML.  These are all data models.  But all can be  
used to represent a generic semantic model, such as RDF.  If there  
were a generic semantic model established with JSON syntax (RDF/ 
JSON?), we could convert microformats to it just as easily as we can  
convert microformats to RDF/XML, but I don't know of any such model,  
and microformats themselves certainly aren't that model.



Elias is coming from an RDF background, and microformats
simply aren't RDF, and they never will be.  And that's a good thing.
If what you want is RDF, just use RDF.


The issue isn't really microformats vs. RDF (except as RDF provides a
model), but microformats vs. RDFa.


I don't think the issue is "vs." at all.  The two approaches solve  
different problems, are interoperable, and collectively improve the  
semantics of the web.  It's all good.  It's just not all the same.   
And the differences are a good thing.



Both microformats and RDFa are addressing the exact same use cases and
requirements (augmenting visible content with structured data).


I don't think the use cases and requirements are the same at all, and  
I hope they never are or we're just doing redundant work here.   
RDFa's use cases include a generic semantic model.  Microformats do  
not.  Microformats have a requirement of making publishing as easy as  
possible to maximize adoption.  RDFa does not share this  
requirement.  These are two different efforts that will lose  
usefulness if merged into one.



RDFa includes namespacing, the lack of which is already a problem in
microformats (witness hCite and the serious awkwardness that title
will be indicate using fn), and which will grow over time as more and
more people want to mark up their content.


I don't think that's a problem.  I think it's just a limited goal of  
solving specific problems as simply as possible.  If people want to  
solve general problems without the constraints of keeping it simple  
for publishers, I'd say they should do that somewhere else.  The RDF  
community seems like an obvious choice.  I hope the various attempts  
at marking up the RDF model in HTML syntax work out well, but I don't  
think that should become a goal of this community.



Moreover, the need to write dedicate code for each new microformat
will also present serious scalability problems.


So then microformats won't scale quickly.  That's okay.  RDF can  
scale quickly while microformats are more accessible to HTML  
publishers.  We can build inter-op tools and everyone can be happy.



Finally, that there's no model at the heart of microformats with clear
extension rules means that the vaunted social process here is a mess.
It's all centralized, and people get frustrated when their pet
property isn't included because they know what that means: the tools
written for the blessed microformats won't see them.


Right, so if you want a semantic model at the heart of your HTML  
markup, there's one already developed in RDFa.  Or you could develop  
another.  But microformats can not have a semantic model beyond HTML  
without becoming more cumbersome to HTML publishers, and that's  
something we should avoid.


From my perspective, all of these attempts to make microformats more  
generalizable are sort of like telling people who are doing math on  
their fingers that they should stop because that won't scale.  That's  
true, but they don't want it to scale right now.  They just want to  
solve a simple problem using familiar tools.  When they get to  
calculus, they'll pull out the calculator.  I don't want to see  
microformats turned into a calculator while there are plenty of  
finger-math problems left to be solved.



So while it might be comforting to dismiss RDFa and "it's not our
problem", I don't think it's good strategy.


A good strategy toward what end?  I think Elias has a problem that  
microformats are not intended to solve.  What he wants to do is have  
a generic semantic model that anyone can use with any type of data,  
and put it in HTML.  What microformats are intended to do is provide  
specific semantic models, not just /in/ HTML, but using the familiar  
tools of HTML as much as possible.


Peace,
Scott
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[S. Sriram]

From: "Bruce D'Arcus" <[EMAIL PROTECTED]>


The issue isn't really microformats vs. RDF (except as RDF provides a
model), but microformats vs. RDFa.

[snip] 

So while it might be comforting to dismiss RDFa and "it's not our
problem", I don't think it's good strategy.



I agree..

Parsing
Per [1] RDFa is akin to a language for microformats, as opposed to 
the current microformats which are a 'particular' defined set of class 
names in a defined order. A 'language parser' could parse all combinations

of 'syntactically' correct RDFa, whereas  with microformats each
particular format requires a particular parser.

Rendering
Now when it comes to rendering the 'parsed output', knowing
what the parsed output is, is necessary. This is where the
need is to understand the 'particular output' *OR* have a
generic container (an hItem or a micro-microformat for an item)
so all-purpose renderers can view 'unknown/particular' parsed
output as a blackbox.

Distributed parsing
Allows for custom microformats to be developed with their
associated custom parsers and the output passed to the rendering 
engine. (possibly discovered by distributed rendering)
Note: This does not need any 'approval process' as all publishers 
are free to do this today i.e. build a custom microformat,

markup their pages appropriately, build a browser plug-in that
understands this and build a cutom renderer.

In other words, in the absence of a language parser (which can 
parse all combinations of a syntactically correct RDFa) the other 
way to accomodate custom microformats (elias's need) is through

distributed parsing.

Another way to look at it is that microformats (with defined
formats == known rendering) are aggregator-friendly, where RDFa and
distributed parsing/rendering are more user/institution friendly
which may explain where google/technorati(aggregator) v. ibm(institution)
are coming from.

My own feeling is that a model which includes both
1. a uf-language (RDFa) and
2. canned formats (microformats)
allows for greater flexibility, with canned formats allowing 
for aggregators/multiple tool vendors, where custom format developers would
have the burden/opportunity of rolling their own renderers. 


[1] http://www.w3.org/TR/xhtml-rdfa-primer/
S. Sriram

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Bruce D'Arcus]

On 12/5/06, Scott Reynen <[EMAIL PROTECTED]> wrote:

...


In HTML or JSON, new formats need new parsers, which must be written
by someone.


Exactly. The point is if you have a generic model you have a generic parser.


Elias is coming from an RDF background, and microformats
simply aren't RDF, and they never will be.  And that's a good thing.
If what you want is RDF, just use RDF.


The issue isn't really microformats vs. RDF (except as RDF provides a
model), but microformats vs. RDFa.

Both microformats and RDFa are addressing the exact same use cases and
requirements (augmenting visible content with structured data).

RDFa includes namespacing, the lack of which is already a problem in
microformats (witness hCite and the serious awkwardness that title
will be indicate using fn), and which will grow over time as more and
more people want to mark up their content.

Moreover, the need to write dedicate code for each new microformat
will also present serious scalability problems.

Finally, that there's no model at the heart of microformats with clear
extension rules means that the vaunted social process here is a mess.
It's all centralized, and people get frustrated when their pet
property isn't included because they know what that means: the tools
written for the blessed microformats won't see them.

So while it might be comforting to dismiss RDFa and "it's not our
problem", I don't think it's good strategy.

Bruce
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[S. Sriram]

From: "Scott Reynen" <[EMAIL PROTECTED]>



2. Place a yadiservices discovery pointer to where parser(s)


What you've described above is a process for converting all  microformats 
to JSON, but that doesn't really solve the problem Elias  described.  It 
just changes the format.  Each individual parser still  needs to figure 
out what the JSON means, where before they had to  figure out what the 
HTML means.




In point of fact it exactly solves elias's problem in somewhat the same way 
that

inline RDFa does. Because of the key-value pairs retuned by JSON.

Take Elias's hCard example [1] with the need for additional attributes i.e.
blog-url, activity-url etc. and the inability to 'add new
properties' to an existing microformat. In the distributed parser model, the 
returned
JSON would allow all uf-aware-browser-apps to look only for hCard data and 
allow
'uf-aware-special-browser-apps' to seek out the additional attributes i.e. 
blog-url etc.

satisfying elias's need.

In other words by looking at parsing/rendering as two seperate and distinct
steps, with ditributed parsing one can accomodate 'generic' formats and
'custom' formats and one can accomodate 'generic' rendering and 'custom'
rendering.

One could also in theory extend the YADIS service to offer a uf-rendering
service, so a browser could look at uf-authored page, send the uf-snippet to
the 'discoverd' uf2json parser, and than send the json to the discovered 
'uf-json-renderer/storer'.etc.


[1] 
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/008500.html


S. Sriram 


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Scott Reynen]

On Dec 5, 2006, at 10:48 AM, S. Sriram wrote:


From: "Mike Schinkel" <[EMAIL PROTECTED]>

http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- 
December/00

8462.html

I wonder if his issues can be addressed?


Ian said:


"class", "rel", and "profile" are the extension mechanism for HTML


And Elias said:


We have tried using microformats as an extension mechanism for HTML


That response confuses the issues here.  Ian pointed out the only  
allowed methods of extending HTML and said that microformats use  
these methods.  That Elias is unsatisfied with these methods is a  
problem with HTML, not with microformats.  We're not in charge of  
HTML here.



How about a distributed parser-discovery service

More specifically a YADIS discovered JSON returning uf-specific  
parser:


1. Place an entry on the uf-authored page detailing the ufs-used



As Ian mentioned in the message Elias responded to, HTML already has  
this functionality with profile headers:


http://microformats.org/wiki/profile-uris


2. Place a yadiservices discovery pointer to where parser(s)
maybe found,  (on the same uf-authored page)




3. add parser service data to the (existing) yadis file pointed to  
within

the uf-authored page.


   
   http://openid.net/signon/1.0
   http://www.livejournal.com/openid/server.bml
   
   
   http://microformats.org/hreview/1.0
   http://www.blah.com/path/to/uf2json-parser
   
   
   http://mysite.com/hwidget/1.0
   http://www.mysite.com/path/to/uf2json-parser
   


4. ..domain../path/to/uf2json-parser is a REST-call that is passed
a 'uf-snippet' and returns a JSON object.
Browsers that are uf-aware would call the parser with the uf-snippet,
and than hand of the JSON to the storing module.

CONS: The parser needs to be 'hosted', incurring bandwidth costs.
PROS: Roll your own microformat and parser - or - *leave your html
as is and just build a parser for it and point tothe parser from  
within the page.*


What you've described above is a process for converting all  
microformats to JSON, but that doesn't really solve the problem Elias  
described.  It just changes the format.  Each individual parser still  
needs to figure out what the JSON means, where before they had to  
figure out what the HTML means.


In HTML or JSON, new formats need new parsers, which must be written  
by someone.  Elias is coming from an RDF background, and microformats  
simply aren't RDF, and they never will be.  And that's a good thing.   
If what you want is RDF, just use RDF.


Peace,
Scott

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[S. Sriram]

From: "Mike Schinkel" <[EMAIL PROTECTED]>



http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/00
8462.html

I wonder if his issues can be addressed?



How about a distributed parser-discovery service

More specifically a YADIS discovered JSON returning uf-specific parser:

1. Place an entry on the uf-authored page detailing the ufs-used


2. Place a yadiservices discovery pointer to where parser(s)
maybe found,  (on the same uf-authored page)

content="http://www.blahblah.com/path/to/yadis-file"; />


3. add parser service data to the (existing) yadis file pointed to within
the uf-authored page.


   
   http://openid.net/signon/1.0
   http://www.livejournal.com/openid/server.bml
   
   
   http://microformats.org/hreview/1.0
   http://www.blah.com/path/to/uf2json-parser
   
   
   http://mysite.com/hwidget/1.0
   http://www.mysite.com/path/to/uf2json-parser
   


4. ..domain../path/to/uf2json-parser is a REST-call that is passed
a 'uf-snippet' and returns a JSON object.
Browsers that are uf-aware would call the parser with the uf-snippet,
and than hand of the JSON to the storing module.

CONS: The parser needs to be 'hosted', incurring bandwidth costs.
PROS: Roll your own microformat and parser - or - *leave your html
as is and just build a parser for it and point tothe parser from within the 
page.*


S. Sriram

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Ben Ward]

On 5 Dec 2006, at 11:30, Mike Schinkel wrote:

For those on this list who are not following [whatwg], here is an
interesting thread about inability to use Microformats:

http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006- 
December/00

8462.html

I wonder if his issues can be addressed?


I'm not sure if they can, or not here at least. What I get from his  
message is not a problem with any specific Microformat, but that IBM  
finds the class/rel/rev/profile extension mechanism of HTML too  
limiting for their needs.


In particular, he gives an example of ‘customers submitting their own  
microformats’, which is not the same as what we refer to as  
‘microformats’ at all. In fact, such broad user-defined formats  
sounds distinctly out-of-scope of our efforts.


If handling a large number of discrete user submitted bespoke formats  
is IBM's goal on their project, it's comprehensible that the  
extension mechanisms in HTML probably are inappropriate. Therefore, I  
think they're taking the right path in asking the WHATWG for a more  
suitable mechanism for them and their goal, but it doesn't really  
expose any problems with well specified microformats here.


Ben
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Comments from IBM/Lotus rep about Microformats

[Bruce D'Arcus]

On 12/5/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:

For those on this list who are not following [whatwg], here is an
interesting thread about inability to use Microformats:

http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/00
8462.html

I wonder if his issues can be addressed?


I think the only way it can be addressed is with some effort to
harmonize microformats and RDFa, which is not going to happen for what
seem to me largely political reasons.

The fact that we can't have a title property in hCite is already
evidence of the practical problems that will result without such an
effort.

FWIW. Elias is an engineer (who writes code; "rep" sounds to me more
marketing, but maybe tha's just me).

Bruce
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss