Re: [uf-discuss] re: HTML5 support

[Philip Jägenstedt]

On Thu, 22 Jul 2010 21:15:48 +0200, Angelo Gladding   
wrote:



Does Microdoata check syntax as well? If so, how does it know what syntax
to look for without sniffing the vocabulary specification? e.g. How does  
the
parser know to store http://microformats.org/wiki/hcard#bday as a  
datetime?


No, there's no checking of the vocabulary-specific rules. When it comes to  
dates, those are expressed using , so you can validate those by  
simply using an HTML validator. The general constraints of microdata can  
also be checked by an HTML validator, but I don't know how far along  
validator.nu is in its support yet.


--
Philip Jägenstedt
Core Developer
Opera Software

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

Re: [uf-discuss] re: HTML5 support

[Oli Studholme]

Hey Angelo,

On Fri, Jul 23, 2010 at 4:51 AM, Angelo Gladding  wrote:
> On Thu, Jul 22, 2010 at 7:20 AM, Oli Studholme
>  wrote:
>> 宮野衆 is the Japanese name Miyano (宮野) Shu (衆) (well, probably ― there
>> may be other readings for 衆). As Philip correctly guesses, Miyano is
>> the family name, so inserting any form of space character would give
>> an incorrectly reversed name using implied “n” optimisation.
>
> My original intentions were to fall back on @lang in case sniffing
> Unicode ranges couldn't
> handle all of the cases. However, if that were the case, would it too
> be sufficiently magic?
>
> As I mentioned to Philip above, I'll draft the algorithm and post it
> back to be more clear.

I think the magic part is less of a problem than the magic sometimes
not working part. You’ll also need to convert to Unicode for pages in
other encodings (three others used in Japan), while keeping in mind
encodings are sometimes not declared.

If you need any help for Japanese let me know

peace - oli

PS speaking of encodings I recently saw a Japanese page using two
different encodings (second via iframe), neither of which were
declared. Mojibake disaster! :O
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] re: HTML5 support

[Angelo Gladding]

On Thu, Jul 22, 2010 at 7:20 AM, Oli Studholme
 wrote:
> 宮野衆 is the Japanese name Miyano (宮野) Shu (衆) (well, probably — there
> may be other readings for 衆). As Philip correctly guesses, Miyano is
> the family name, so inserting any form of space character would give
> an incorrectly reversed name using implied “n” optimisation.

My original intentions were to fall back on @lang in case sniffing
Unicode ranges couldn't
handle all of the cases. However, if that were the case, would it too
be sufficiently magic?

As I mentioned to Philip above, I'll draft the algorithm and post it
back to be more clear.

-- 
Angelo Gladding
ang...@gladding.name

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

Re: [uf-discuss] re: HTML5 support

[Angelo Gladding]

On Wed, Jul 21, 2010 at 7:07 AM, Stephen Paul Weber
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Somebody claiming to be Toby Inkster wrote:
>> On Tue, 20 Jul 2010 08:29:48 -0400
>> Stephen Paul Weber  wrote:
>>
>> > Having written significant code both in-browser and out to parse
>> > microformats, I find the claim that parsing them using the DOM is
>> > "not practical" shocking.  What would you prefer?
>>
>> Parsing microformats via the DOM is not practical. Parsing them any
>> other way is even worse though.
>>
>> While writing DOM code to parse a particular site's implementation of
>> say, hCard, is pretty trivial, generalising that to support all the
>> variations of how hCard is marked up in the wild is a lot of work.
>>
>> As a comparison, I have written Perl parsers[*] for microformats, RDFa
>> and Microdata. Here are the lines-of-code counts for each, excluding
>> documentation, comments and blank lines:
>>
>> The amount of code needed to parse microformats is clearly different
>> from the other formats.
>
> Sure, but you're comparing apples and oranges.  RDF and microdata are more
> like JSON and XML: popular but useless by themselves.  They're just generic
> containers.  So, yes, you can trivially parse out the KVPs they encode, but
> you have no idea what those are, what they mean, what the relationships
> between them are, nothing.  So you would have to write more code to
> implement each specific vocabulary you were interested in, and do useful
> stuff with it.  The microformats parsers, because they're parsing an actual
> vocabulary instead of a container format, yes there will be some more code,
> because both steps are happening at once.
>
> The data you get out is actually the data you want, that makes sense, though.
> When I want profile data, I write an hCard parser and grab it.  The same
> deal with microdata would normally be done with a seperate "generic" parser
> and then the code to throw out all vocabularies I don't want, and then the
> one to massage into an internal data format that I want the vocabularies
> that I do.

On Wed, Jul 21, 2010 at 2:09 AM, Toby Inkster  wrote:
> Microdata  :  945
> RDFa 1.0   : 1265
> RDFa 1.1 [**]  : 2611
> microformats   : 9455

It's tough to argue with an order of magnitude difference with
the most complete, public universal implementation to date.

So what is the fundamental difference between the two approaches?

It appears that Microdata takes us through lexical analysis and leaves us
with a parse tree (?) while Microformats take us through the secondary stage
of syntactic/semantic analysis and leaves us with a semantic graph (?).

Does Microdoata check syntax as well? If so, how does it know what syntax
to look for without sniffing the vocabulary specification? e.g. How does the
parser know to store http://microformats.org/wiki/hcard#bday as a datetime?

- - -

On a related note, how many of our issues does MF2 [1] stand to resolve?
Reading these notes has green-lighted a couple of features I was tentatively
considering for my universal parser. Future proofing my implementation (and
participating in this conversation!) has helped me to better understand the
two approaches' design goals. MF2 looks to be the logical middle-ground
and may very well render much of this conversation moot.

[1]: http://microformats.org/wiki/events/2010-05-02-microformats-2-0

-- 
Angelo Gladding
ang...@gladding.name

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

Re: [uf-discuss] re: HTML5 support

[Angelo Gladding]

On Thu, Jul 22, 2010 at 6:53 AM, Philip Jägenstedt  wrote:
> On Wed, 21 Jul 2010 18:04:42 +0200, Sarven Capadisli 
> wrote:
>
>> On Wed, 2010-07-21 at 16:33 +0200, Philip Jägenstedt wrote:
>>>
>>> On Wed, 21 Jul 2010 15:46:08 +0200, Stephen Paul Weber
>>>  wrote:
>>>
>>> > -BEGIN PGP SIGNED MESSAGE-
>>> > Hash: SHA256
>>> >
>>> > Somebody claiming to be Philip Jägenstedt wrote:
>>> >> On Tue, 20 Jul 2010 15:47:19 +0200, Scott Reynen
>>> >>  wrote:
>>> >>
>>> >> >Distributed vocabulary development requires a general purpose
>>> >> >solution.  Microformats don't have that requirement, so
>>> >> >vocabulary-specific solutions are common.
>>> >>
>>> >> Yes, which is why general purpose parsers cannot exist, and why
>>> >> browser support is unlikely.
>>> >
>>> > I'm pretty sure Firefox already supports µfs...
>>>
>>> Are you sure it's not a plugin? If not, I'd be very interested to see it
>>> in action.
>>>
>>
>> It has some support. See also resource://gre/modules/Microformats.js and
>> https://developer.mozilla.org/en/Using_microformats
>>
>> Probably the best way to see it in action is via JetPack:
>> https://jetpack.mozillalabs.com/
>
> Thanks, that's pretty cool. However, I note that this is only loaded on
> demand. Looking for e.g. hcards on every page parsed is not quite the same
> thing, and is what you'd need to do to have a button similar to the orange
> "feed" button pop up for all pages where there's something to add to the
> address book or calendar.
>

Firefox's Operator Plugin [1] has sniffed the microformats of each and every
document that I have opened on multiple computers (ranging from slow to fast)
for several years now. Make sure to install appropriate user scripts [2].

[1]: https://addons.mozilla.org/en-US/firefox/addon/4106/
[2]: http://kaply.com/weblog/operator-user-scripts/

-- 
Angelo Gladding
ang...@gladding.name

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

Re: [uf-discuss] re: HTML5 support

[Philip Jägenstedt]

On Wed, 21 Jul 2010 18:04:42 +0200, Sarven Capadisli   
wrote:



On Wed, 2010-07-21 at 16:33 +0200, Philip Jägenstedt wrote:

On Wed, 21 Jul 2010 15:46:08 +0200, Stephen Paul Weber
 wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Somebody claiming to be Philip Jägenstedt wrote:
>> On Tue, 20 Jul 2010 15:47:19 +0200, Scott Reynen
>>  wrote:
>>
>> >Distributed vocabulary development requires a general purpose
>> >solution.  Microformats don't have that requirement, so
>> >vocabulary-specific solutions are common.
>>
>> Yes, which is why general purpose parsers cannot exist, and why
>> browser support is unlikely.
>
> I'm pretty sure Firefox already supports µfs...

Are you sure it's not a plugin? If not, I'd be very interested to see it
in action.



It has some support. See also resource://gre/modules/Microformats.js and
https://developer.mozilla.org/en/Using_microformats

Probably the best way to see it in action is via JetPack:
https://jetpack.mozillalabs.com/


Thanks, that's pretty cool. However, I note that this is only loaded on  
demand. Looking for e.g. hcards on every page parsed is not quite the same  
thing, and is what you'd need to do to have a button similar to the orange  
"feed" button pop up for all pages where there's something to add to the  
address book or calendar.


--
Philip Jägenstedt
Core Developer
Opera Software

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

Re: [uf-discuss] re: HTML5 support

[Oli Studholme]

Hey All,

Wow, this has turned into a really interesting thread. Thank you all
for your input.

I just want to address a couple of points… ;)

On Wed, Jul 21, 2010 at 6:27 PM, Philip Jägenstedt  wrote:
>>>
>>> The main problem with this is that due to lazy copy-pasting, lang="en" is
>>> often used even when the language isn't English. Also, in the case of
>>> e.g.
>>> Facebook, lang="en" would be correct for the page itself, but people's
>>> names
>>> aren't in English anyway.
>>
>> Check out http://ja-jp.facebook.com/people/gong-ye-zhong/10456401743
>> ..宮野衆...
>>
>> 宮野 can log in today and, without any cooperation from Facebook, append
>> a U+200B (zero-width space [1]) to his first name (regardless of the
>> input taking the form of one or two boxes), and immediately reap the
>> benefits of such an `n` optimization without negatively affecting UI,
>> sort order, etc.
>
> I don't speak Japanese, but I think 宮野 is the family name and 衆 is the given
> name. By not doing anything the 'n' optimization will incorrectly guess that
> the family name is 宮野衆 and given name unknown. By inserting a zero-width
> space, it will instead incorrectly guess that 宮野 is the given name and 衆 is
> the family name. Either way it's incorrect.

宮野衆 is the Japanese name Miyano (宮野) Shu (衆) (well, probably — there
may be other readings for 衆). As Philip correctly guesses, Miyano is
the family name, so inserting any form of space character would give
an incorrectly reversed name using implied “n” optimisation.

While Tantek’s suggested workaround of using the declared language
would work on the Japanese Facebook site, the @lang changes based on
location. For example:
http://www.facebook.com/people/gong-ye-zhong/10456401743
has the same content with 

In addition to the points Philip made about @lang often being wrong, a
lot of the time it isn’t even present (well in Japan anyhow). I did a
quick search on a popular Japanese surname (28 mil results in Google),
and only 6 of the first 10 results declared @lang:
http://microformats.org/wiki/hcard-issues-resolved#resolved_2010
As you can guess, it goes downhill from there.
(btw, thanks for your comments Tantek — let me know if you want me to
open the separate issue)

Philip, the implied “n” optimisation doesn’t work on single word
names; they would get implied “nickname” optimisation instead.



On Tue, Jul 20, 2010 at 9:29 PM, Stephen Paul Weber
 wrote:
> Microformats data is not "hidden"

In general this is true for microdata too.

> One of the benefits of using the real semantics of the page, and not some  
> hacked-in layer like microdata, is that it works well with existing tools and 
> markup.  CSS styling of microformats, for example, "just works" and I use it 
> all the time.  DOM access similarly works well.

“hacked-in”? It’s specced on w3.org and includes an API. Also, check
out the CSS 2.1 [attr] selector.



On Wed, Jul 21, 2010 at 4:55 AM, Angelo Gladding  wrote:
>  However, if optimizations
>  can yield 80%+ positive results when viewed in aggregate I personally give
>  a little bit of magic a big thumbs up.

I’m guessing this wasn’t the metric by which using datetimes in the
abbr design pattern was depreciated



On Tue, Jul 20, 2010 at 2:41 PM, Martin McEvoy  wrote:
> Im sorry but you cannot express *microformats* in microdata if you do, its
> cute, but It isn't a microformat because microformats *only* use  class
> names, and a few choice rel-values.  If you move a microformat away from
> @class its no longer a microformat and shouldn't be described as such

I’m sorry, but I don’t think this is correct. You’re mixing the
technology with the goal (and forgetting VoteLinks and @profile ;-)

“Designed for humans first and machines second, microformats are a set
of simple, open data formats built upon existing and widely adopted
standards” — Microformats wiki about page

“Microformats are more than simply a technology like CSS or XHTML—they
are an approach to solving the important problem of creating a rich
semantic markup” — Microformats, John Allsopp, p6


peace - oli

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

Re: [uf-discuss] re: HTML5 support

[Sarven Capadisli]

On Wed, 2010-07-21 at 16:33 +0200, Philip Jägenstedt wrote:
> On Wed, 21 Jul 2010 15:46:08 +0200, Stephen Paul Weber  
>  wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Somebody claiming to be Philip Jägenstedt wrote:
> >> On Tue, 20 Jul 2010 15:47:19 +0200, Scott Reynen
> >>  wrote:
> >>
> >> >Distributed vocabulary development requires a general purpose
> >> >solution.  Microformats don't have that requirement, so
> >> >vocabulary-specific solutions are common.
> >>
> >> Yes, which is why general purpose parsers cannot exist, and why
> >> browser support is unlikely.
> >
> > I'm pretty sure Firefox already supports µfs...
> 
> Are you sure it's not a plugin? If not, I'd be very interested to see it  
> in action.
> 

It has some support. See also resource://gre/modules/Microformats.js and
https://developer.mozilla.org/en/Using_microformats

Probably the best way to see it in action is via JetPack:
https://jetpack.mozillalabs.com/

-Sarven


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

Re: [uf-discuss] re: HTML5 support

[Philip Jägenstedt]

On Wed, 21 Jul 2010 15:46:08 +0200, Stephen Paul Weber  
 wrote:



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Somebody claiming to be Philip Jägenstedt wrote:

On Tue, 20 Jul 2010 15:47:19 +0200, Scott Reynen
 wrote:

>Distributed vocabulary development requires a general purpose
>solution.  Microformats don't have that requirement, so
>vocabulary-specific solutions are common.

Yes, which is why general purpose parsers cannot exist, and why
browser support is unlikely.


I'm pretty sure Firefox already supports µfs...


Are you sure it's not a plugin? If not, I'd be very interested to see it  
in action.


--
Philip Jägenstedt
Core Developer
Opera Software

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

Re: [uf-discuss] re: HTML5 support

[Stephen Paul Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Somebody claiming to be Toby Inkster wrote:
> On Tue, 20 Jul 2010 08:29:48 -0400
> Stephen Paul Weber  wrote:
> 
> > Having written significant code both in-browser and out to parse
> > microformats, I find the claim that parsing them using the DOM is
> > "not practical" shocking.  What would you prefer?
> 
> Parsing microformats via the DOM is not practical. Parsing them any
> other way is even worse though.
> 
> While writing DOM code to parse a particular site's implementation of
> say, hCard, is pretty trivial, generalising that to support all the
> variations of how hCard is marked up in the wild is a lot of work.
> 
> As a comparison, I have written Perl parsers[*] for microformats, RDFa
> and Microdata. Here are the lines-of-code counts for each, excluding
> documentation, comments and blank lines:
> 
> The amount of code needed to parse microformats is clearly different
> from the other formats.

Sure, but you're comparing apples and oranges.  RDF and microdata are more
like JSON and XML: popular but useless by themselves.  They're just generic
containers.  So, yes, you can trivially parse out the KVPs they encode, but
you have no idea what those are, what they mean, what the relationships
between them are, nothing.  So you would have to write more code to
implement each specific vocabulary you were interested in, and do useful
stuff with it.  The microformats parsers, because they're parsing an actual
vocabulary instead of a container format, yes there will be some more code,
because both steps are happening at once.

The data you get out is actually the data you want, that makes sense, though.
When I want profile data, I write an hCard parser and grab it.  The same
deal with microdata would normally be done with a seperate "generic" parser
and then the code to throw out all vocabularies I don't want, and then the
one to massage into an internal data format that I want the vocabularies
that I do.

- -- 
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJMRv8JAAoJENEcKRHOUZze7lYP/A9AD+Vnwy2mEM+zOB7QITFc
FlrVzGksiOnIyPtKIXgMG8Sm8doPRrG8JC0RtCA7V3BhVmNR8dry+5A8PCCpLOyl
8CUym6G10RYduQQ0rdQCYMB6E37BgAq3Vl9oi9xUSZwsbJepEdIrSeifUZnbYtA0
ZMD/ADmLBYyqeHUf1/0So/m7W4vxtki7eUX0i95YgW997AFntKYZBfY2gtOTvvur
Cx53jMWGkZdNgvGg/Mc9eyR011bPec7RtDkbYJJoUaVCiezxk1wFhzR6lLgcoRyB
ZM4zEIBAOGS3UrT+pchX6OYGpL/3JGdCFdUkFPLbQlH1lOO1X1brogS3rJRDIyGk
X1DQu0Md0b03vzw/wW5tIs93TCN2uGjiwXjC4ytFY7wuk9K9vwtZQQL6O8a9dJTf
9QFdGopQvn5YIFbVK/3p+9lPJUmu4+BljEDSVtQYzT0RA3b/qXvgJmqOzYBau9Eo
2YczFkjF69y3llaX5zAoOmQHhD1uKYjZUbOj+8fHZSKccPSwZXuXnR+sSrWlm3nR
Hr81QftUoO3IztBqargQVXbDiW+f+BItb1xPm343sxiFSVfXDFtcUp2kaEvF39no
LAG/XPnLDhV9FtDTwXwbhbfBQ4dCxRxQIkwfD8Jf5uFVLyWfpyB3+90yEdPVjhnO
wb76GF2GtcZiGY/5J/AN
=ORD1
-END PGP SIGNATURE-
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] re: HTML5 support

[Stephen Paul Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Somebody claiming to be Philip Jägenstedt wrote:
> On Tue, 20 Jul 2010 15:47:19 +0200, Scott Reynen
>  wrote:
> 
> >Distributed vocabulary development requires a general purpose
> >solution.  Microformats don't have that requirement, so
> >vocabulary-specific solutions are common.
> 
> Yes, which is why general purpose parsers cannot exist, and why
> browser support is unlikely.

I'm pretty sure Firefox already supports µfs...

- -- 
Stephen Paul Weber, @singpolyma
See  for how I prefer to be contacted
edition right joseph
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJMRvogAAoJENEcKRHOUZzekwMQALfvKvcVsCiFQbUEwIBLqMDe
qutM1KNYLrF036gumqyoBliK59qzBzuxWGLhbgEBqF5lLaqWPKolU5Dd3EzpW6HV
uYGpPrdw5L65L7NNUBNlrEfMkA1sa/EnF57at+/kcWhJSN5DG1uMJv5C9/pqdr4n
Zcw53uUb+NP9FY75zEL1jgjeQFR5s1pIkBkx1gjipcPmvDQ7TZ8VQ+li0Rpja4ON
T0jLLJ3qQVvmNmV1xrB6wI9fzopZ5LJycvfZaRONO7hPes1MIEuZWUiKFKho+h/4
Z1pY/twwCHI7VnnY7gbBh3U08ni1iYaaTbkphV153uxjRWSoBz0a8RxJ7U+StO6h
dFX0WKt7GY+9kVbQiymvxB6fwUaiEJO5sUZQ4xpesXhwqcfRnwbFipzm4veVIqAb
TfYdakiMkovKl5fAD1q671hJ82zfdI2PW2V8vPEWPc45yjasZMG59jHecCoFirFP
Ir29bk2mEJOuce+zvboRod5yINuEXTzShv86dZyi9oFFLO3TQxQezXev+SGnd7lI
LH6xbkYnfdSmTKjHK2v+edciIKt1z+B9ahe7YQxBWOlzcTpUXb6xTIspbIboc/0v
CeRdKaTlPkzsfHqbs66/LSHIekippH4m4/7sB0ZICjCDjkQgElrhewGmOjYuxXes
E3i3A4nfX9G5DxYl6asX
=JAD3
-END PGP SIGNATURE-
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] re: HTML5 support

[Philip Jägenstedt]

On Tue, 20 Jul 2010 15:47:19 +0200, Scott Reynen   
wrote:



On Jul 19, 2010, at 8:57 PM, Oli Studholme wrote:

Microdata doesn't go out of its way to be compatible with existing  
RDF vocabularies


Maybe not specific vocabularies (that's kind of my point), but RDF  
itself is clearly a major consideration.  There's a whole section on  
it:


http://www.w3.org/TR/microdata/#rdf


No. There’s a sub-sub-section on converting to RDF, just as there are
for converting to JSON and Atom. That’s not a design goal, it’s
specified interoperability.


They're mentioned as "requirements" in the original announcement:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019681.html

But again, the RDF syntax doesn't matter.  This is the important part  
for me:


"Distributed vocabulary development should be possible; it should not  
require coordination through a centralised system."


Distributed vocabulary development requires a general purpose solution.   
Microformats don't have that requirement, so vocabulary-specific  
solutions are common.


Yes, which is why general purpose parsers cannot exist, and why browser  
support is unlikely.


I'd argue it is a bad idea in microdata, but not in microformats,  
because of the very distinction I'm trying to draw between the two.


As far as microdata goes it’s irrelevant — that’s something decided by
the *vocabulary* author.


I don't think that's really true, though, and I think this is exactly  
why n optimization was removed.  For every other microdata property, the  
value is determined by following the parsing rules in the microdata spec:


http://www.w3.org/TR/microdata/#values

With n optimization, undeclared properties are given values via a  
completely different parsing model.  This "magic"  may not be explicitly  
disallowed, but it doesn't really fit with the general design of  
microdata.


The magic was in the vCard extraction algorithm:  



The DOM isn't changed, that would indeed be a very bad fit with the  
overall design.



On Jul 19, 2010, at 10:05 PM, Angelo Gladding wrote:


Could it be said that microdata intends to do to Microformat syntax
what HTML5 did to HTML4 syntax rules in the sense that parsing is
unambiguous and easier to validate normativity?


I'd say that's true as far as what they both do, but not how they do  
it.  HTML5 makes parsing unambiguous by describing a wide variety of  
parsing rules for invalid content.  I'd say such tolerance of human  
error is more in line with the microformats approach.


Microdata, on the other hand, simply changes the syntax to reduce the  
risk of invalid content.  So in terms of strategy for making parsing  
unambiguous, microdata looks more like XHTML to me.


HTML5 parsing is also unambiguous. The only reason it's so ridiculously  
complex is because it's needed to parse real markup on the web. With  
microdata there was no existing content, so it's possible to make a more  
sane definition. But of course, some parts may be too strict and I've  
previously left feedback and had gotten the spec changed due to this. If  
there are more things which are unnecessarily strict and makes it  
difficult for authors, please do send mail to the WHATWG or W3C so that it  
can be fixed.


--
Philip Jägenstedt
Core Developer
Opera Software

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

Re: [uf-discuss] re: HTML5 support

[Philip Jägenstedt]

On Tue, 20 Jul 2010 21:55:38 +0200, Angelo Gladding   
wrote:


On Tue, Jul 20, 2010 at 3:25 AM, Philip Jägenstedt   
wrote:
On Tue, 20 Jul 2010 06:05:06 +0200, Angelo Gladding  


wrote:


Can an enlightened soul describe in which ways microdata is actually
superior to profiled poshformats?


Microdata should be compared to the class attributes and the various
patterns that microformats use, not any specific vocabulary.


Of course. Let me clarify. A `microformat` is a poshformat that has
undergone a relatively laborious process of research and brainstorming
to capture real world user requirements to make a minimal vocabulary
that can capture ~80% of current usage patterns. Microdata is a set of
rules governing a syntax. Hence my comparison of microdata to
poshformats, which are essentially microformats sans the due
diligence.


Right, designing vocabularies is hard and requires due diligence. That's  
true no matter what the syntax is.



The main benefit is that parsing becomes well-defined


Ain't that the truth.


and simple.


Or is it? I wonder how different the two sets of supporting algorithms
might look face to face once fully documented and implemented.

The Microformats wiki makes the following comparison to microdata:

1. `itemprop` - is a more specific version of class, for field names.
2. `subject` - allows semantically linking within the page.
Conceptually similar to the include-pattern.
3. `itemref` - allows including properties elsewhere on the page that
are not descendants of itemscope. Takes space-separated ids (for
example itemref="address phone" would include the elements with
id="address" and id="phone"). Conceptually similar to the
include-pattern.
4. `content` - on the meta element can be used to include invisible
data that is not part of the content. As current browsers move meta
inside , make sure to include via `itemref`. Conceptually
similar to the 'value-title' feature of the value-class-pattern.
5. `itemscope` - identifies blocks to be marked as structured data.
Conceptually similar to the mfo brainstorming.
6. `itemtype` - to specify the type for an item (for example:
itemtype="http://microformats.org/profile/hcard";).


What wiki page is this from? subject has been replaced by itemid. I can't  
understand what the similary with the include-pattern could possibly be,  
though.



Distilled down:

1. @class
2/3. include-pattern/table-header-pattern
4. value-class-pattern
5. "mfo"
6. rel-profile

Sounds to me like the same sort of desire for absolute normativity
that [non-HTML5] XHTML once attempted to burden the entirety of
humanity with. Ironically, HTML5 has deprecated such a style in favor
of a seemingly more flexible Microformat-esque syntax.


Putting XHTML2 aside, one of the main achievements of HTML5 is having  
formalized how to parse all the sloppy, broken HTML out there (a.k.a. "tag  
soup"). While the syntax is flexible to authors, there's no flexibility  
whatsoever for an implementor how to parse it. The result will always be  
the same. In my view, microdata is to microformats what the HTML5 parser  
is to HTML4. It makes it possible to parse, without ever guessing, all the  
microdata items on a page. While it's really easy to write a microformat  
parser in JavaScript, you're not going to see that built into a browser,  
where each vocabulary needs a new parser. Microdata also hasn't been  
implemented by any browser yet, but I'm pretty sure it's going to happen  
if it takes off.



http://microformats.org/profile/hcard";>



Considering your affiliation with Opera, what might I ask are your
feelings about Operator?


I've heard of it before, it looks like a custom Opera distribution? It has  
nothing to do with microformats or microdata as far as I can tell.



which really isn't really practical with microformats when the
data is hidden in class attributes together with everything else.


As I alluded to above I see this as a complete non-issue yet you are
most certainly not the first to bring it up. What am I missing?


If a browser is going to support some kind of embedded data vocabularies  
(like events or contacts), the code for parsing it isn't going to be  
written in JavaScript using the DOM, it's going to be in C++ or C  
operating on the internal datastructures of the browser. To support a  
specific microformat vocabulary, one would have to look through all the  
classes on all elements to find the "root" element, then speculatively  
search its children for the other structures of the microformat. Given  
that the all of the constructs used in microformats are also used for  
completely different things, so most of the data you inspect isn't  
actually going to be what you're looking for. Since one has to do this for  
all documents parsed (and not "on demand" like when finding a particular  
class using document.getElementsByClassName) my guess is that it's going  
to be slow. What's worse, you'll have to write more or this complicated,  
slow 

Re: [uf-discuss] re: HTML5 support

[Toby Inkster]

On Tue, 20 Jul 2010 08:29:48 -0400
Stephen Paul Weber  wrote:

> Having written significant code both in-browser and out to parse
> microformats, I find the claim that parsing them using the DOM is
> "not practical" shocking.  What would you prefer?

Parsing microformats via the DOM is not practical. Parsing them any
other way is even worse though.

While writing DOM code to parse a particular site's implementation of
say, hCard, is pretty trivial, generalising that to support all the
variations of how hCard is marked up in the wild is a lot of work.

As a comparison, I have written Perl parsers[*] for microformats, RDFa
and Microdata. Here are the lines-of-code counts for each, excluding
documentation, comments and blank lines:

Microdata  :  945
RDFa 1.0   : 1265
RDFa 1.1 [**]  : 2611
microformats   : 9455

*  = See .
** = this code actually handles both RDFa 1.0 and 1.1. Whatsmore it can
 handle them embedded in Atom, SVG and OpenDocument Format; not
 just (X)HTML. A pure RDFa-1.1-in-(X)HTML parser could probably be
 written in under 1000 lines of Perl.

The amount of code needed to parse microformats is clearly different
from the other formats.

Another difference is that the Microdata and RDFa 1.0 implementations
can be considered more-or-less complete. (The RDFa 1.1 working drafts
are still somewhat is flux, so the implementation no doubt still needs
changes.) If somebody comes up tomorrow with a new RDFa or Microdata
vocabulary for describing cows, or bread makers, or train timetables,
it will work out of the box. For microformats, that's not the case -
code needs to be written.

So you end up with a chicken-and-egg situation with nobody implementing
tools for a new draft microformat because it's not used in the wild;
nobody using it in the wild because of a lack of tool support; and the
microformat never progressing beyond draft status because of lack of
implementation experience, and uncertainty about how it might work in
the wild. That's why we haven't had any of the draft microformats on
the wiki move out of draft status in the last four years or so; or at
least it's a major contributory factor.

-- 
Toby A Inkster



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

Re: [uf-discuss] re: HTML5 support

[Stephen Paul Weber]

> On Tue, 20 Jul 2010 06:05:06 +0200, Angelo Gladding
>      wrote:
> 
> > Can an enlightened soul describe in which ways microdata is actually
> > superior to profiled poshformats?
> 
> Microdata should be compared to the class attributes and the various   
> patterns that microformats use, not any specific vocabulary. The main   
> benefit is that parsing becomes well-defined and simple. That's why it's
>     possible to define a JavaScript API for accessing microdata items on a
>     page, which makes the data useful to the page itself, not only
> external     scrapers. It also makes it feasible to make browser features
> like "add to     address book" or "add to calendar", which really isn't
> really practical     with microformats when the data is hidden in class
> attributes together     with everything else.

Microformats data is not "hidden".  Microformats are just well-done vocabulary 
specifications using the semantics of HTML.  Is one of thlse semantics @class? 
Absolutely.  It is by no means a primary or most important one.

One of the benefits of using the real semantics of the page, and not some  
hacked-in layer like microdata, is that it works well with existing tools and 
markup.  CSS styling of microformats, for example, "just works" and I use it 
all the time.  DOM access similarly works well.

Having written significant code both in-browser and out to parse microformats, 
I find the claim that parsing them using the DOM is "not practical" shocking.  
What would you prefer?  Microformats psrsers are usually very easy to write 
precisely because they use the page's existing semantics, and thus are easily 
exposed to the tools used for all DOMscripting (including, but not limited to, 
selecting elements by class).

Then again, I'm very biased.  Microdata, like other superfluous parts of HTML5 
(up there with audio and video tags) just makes me sad.  Too much NIH 
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] re: HTML5 support

[Scott Reynen]

On Jul 19, 2010, at 8:57 PM, Oli Studholme wrote:

>>> Microdata doesn't go out of its way to be compatible with existing RDF 
>>> vocabularies
>> 
>> Maybe not specific vocabularies (that's kind of my point), but RDF itself is 
>> clearly a major consideration.  There's a whole section on it:
>> 
>> http://www.w3.org/TR/microdata/#rdf
> 
> No. There’s a sub-sub-section on converting to RDF, just as there are
> for converting to JSON and Atom. That’s not a design goal, it’s
> specified interoperability.

They're mentioned as "requirements" in the original announcement:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019681.html

But again, the RDF syntax doesn't matter.  This is the important part for me:

"Distributed vocabulary development should be possible; it should not require 
coordination through a centralised system."

Distributed vocabulary development requires a general purpose solution.  
Microformats don't have that requirement, so vocabulary-specific solutions are 
common.

>> I'd argue it is a bad idea in microdata, but not in microformats, because of 
>> the very distinction I'm trying to draw between the two.
> 
> As far as microdata goes it’s irrelevant — that’s something decided by
> the *vocabulary* author.

I don't think that's really true, though, and I think this is exactly why n 
optimization was removed.  For every other microdata property, the value is 
determined by following the parsing rules in the microdata spec:

http://www.w3.org/TR/microdata/#values

With n optimization, undeclared properties are given values via a completely 
different parsing model.  This "magic"  may not be explicitly disallowed, but 
it doesn't really fit with the general design of microdata.

On Jul 19, 2010, at 10:05 PM, Angelo Gladding wrote:

> Could it be said that microdata intends to do to Microformat syntax
> what HTML5 did to HTML4 syntax rules in the sense that parsing is
> unambiguous and easier to validate normativity?

I'd say that's true as far as what they both do, but not how they do it.  HTML5 
makes parsing unambiguous by describing a wide variety of parsing rules for 
invalid content.  I'd say such tolerance of human error is more in line with 
the microformats approach.

Microdata, on the other hand, simply changes the syntax to reduce the risk of 
invalid content.  So in terms of strategy for making parsing unambiguous, 
microdata looks more like XHTML to me.

On Jul 20, 2010, at 4:25 AM, Philip Jägenstedt wrote:

> Microdata should be compared to the class attributes and the various patterns 
> that microformats use, not any specific vocabulary.

Agreed!

> The main benefit is that parsing becomes well-defined and simple.

Right, a lot of it comes down to optimizing for parsers vs. optimizing for 
publishers.  HTML itself is familiar to publishers, but difficult to parse for 
data.  Microformats are limited to HTML to make things simpler for publishers 
at a cost to parsers.  Microdata extends HTML to make things simpler for 
parsers at a cost to publishers.  Of course, publishers and parsers need to 
work together, so these approaches only diverge so far.

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

Re: [uf-discuss] re: HTML5 support

[Angelo Gladding]

On Tue, Jul 20, 2010 at 3:25 AM, Philip Jägenstedt  wrote:
> On Tue, 20 Jul 2010 06:05:06 +0200, Angelo Gladding 
> wrote:
>
>> Can an enlightened soul describe in which ways microdata is actually
>> superior to profiled poshformats?
>
> Microdata should be compared to the class attributes and the various
> patterns that microformats use, not any specific vocabulary.

Of course. Let me clarify. A `microformat` is a poshformat that has
undergone a relatively laborious process of research and brainstorming
to capture real world user requirements to make a minimal vocabulary
that can capture ~80% of current usage patterns. Microdata is a set of
rules governing a syntax. Hence my comparison of microdata to
poshformats, which are essentially microformats sans the due
diligence.

> The main benefit is that parsing becomes well-defined

Ain't that the truth.

> and simple.

Or is it? I wonder how different the two sets of supporting algorithms
might look face to face once fully documented and implemented.

The Microformats wiki makes the following comparison to microdata:

1. `itemprop` - is a more specific version of class, for field names.
2. `subject` - allows semantically linking within the page.
Conceptually similar to the include-pattern.
3. `itemref` - allows including properties elsewhere on the page that
are not descendants of itemscope. Takes space-separated ids (for
example itemref="address phone" would include the elements with
id="address" and id="phone"). Conceptually similar to the
include-pattern.
4. `content` - on the meta element can be used to include invisible
data that is not part of the content. As current browsers move meta
inside , make sure to include via `itemref`. Conceptually
similar to the 'value-title' feature of the value-class-pattern.
5. `itemscope` - identifies blocks to be marked as structured data.
Conceptually similar to the mfo brainstorming.
6. `itemtype` - to specify the type for an item (for example:
itemtype="http://microformats.org/profile/hcard";).

Distilled down:

1. @class
2/3. include-pattern/table-header-pattern
4. value-class-pattern
5. "mfo"
6. rel-profile

Sounds to me like the same sort of desire for absolute normativity
that [non-HTML5] XHTML once attempted to burden the entirety of
humanity with. Ironically, HTML5 has deprecated such a style in favor
of a seemingly more flexible Microformat-esque syntax.

- - -

http://microformats.org/profile/hcard";>
  
 George
 Washington
  


vs

George Washington

- - -

http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>


example


example



vs


example
example

> That's why it's possible to define a JavaScript API for accessing microdata
> items on a page, which makes the data useful to the page itself, not only
> external scrapers. It also makes it feasible to make browser features like 
> "add to
> address book" or "add to calendar",

Considering your affiliation with Opera, what might I ask are your
feelings about Operator?

> which really isn't really practical with microformats when the
> data is hidden in class attributes together with everything else.

As I alluded to above I see this as a complete non-issue yet you are
most certainly not the first to bring it up. What am I missing?

>> Might a "humans first, machines second" CJKV internationalization of
>> `n` optimization be to analyze the contents of the `fn`'s @lang and
>> inner text and use either or both to better determine name order?
>
> The main problem with this is that due to lazy copy-pasting, lang="en" is
> often used even when the language isn't English. Also, in the case of e.g.
> Facebook, lang="en" would be correct for the page itself, but people's names
> aren't in English anyway.

Check out http://ja-jp.facebook.com/people/gong-ye-zhong/10456401743

..宮野衆...

宮野 can log in today and, without any cooperation from Facebook, append
a U+200B (zero-width space [1]) to his first name (regardless of the
input taking the form of one or two boxes), and immediately reap the
benefits of such an `n` optimization without negatively affecting UI,
sort order, etc.

[1] http://en.wikipedia.org/wiki/Zero-width_space

> The only way to get it right is to ask the user both for the full name,
> given name and family name, something I haven't ever seen.

If you haven't seen it, then it isn't even a single way to get it
right -- another
byproduct of Microformats philosophy I believe. However, if optimizations
 can yield 80%+ positive results when viewed in aggregate I personally give
 a little bit of magic a big thumbs up.

> The most practical solution is to not guess at all, and I don't know
> of any negative effects of this.

I just see a tiny hint of dehumanization. ;)

-- 
Angelo Gladding
ang...@gladding.name

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

Re: [uf-discuss] re: HTML5 support

[Ciaran McNulty]

On Tue, Jul 20, 2010 at 1:07 PM, Philip Jägenstedt  wrote:
> Well, it's not in W3C's version of HTML5, they published it as a separate
> spec (which is strange, IMO). Regardless of what spec it is in, it still
> works just the same, so that's OK.

Oh, really? Sorry, I'm out of date in that case.

I think it's bundled together with 'HTML5' in the public consciousness anyhow.

-Ciaran

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

Re: [uf-discuss] re: HTML5 support

[Philip Jägenstedt]

On Tue, 20 Jul 2010 13:05:56 +0200, Ciaran McNulty  
 wrote:


On Tue, Jul 20, 2010 at 5:05 AM, Angelo Gladding   
wrote:

Can an enlightened soul describe in which ways microdata is actually
superior to profiled poshformats?


To me it's not a question of Microdata vs POSH, it's more like
Microdata vs class attributes where both are methods that can be used
in POSH style data embedding.

The main arguments (and I present these without necessarily agreeing!)
seem to be:

1. Class is ingrained as a CSS hook mechanism. Most people on this
list are fine with class being used for other purposes, but despite
that the argument comes up incredibly often that using class is
somehow a 'hack'. Microdata overcomes that, so right or wrong, it may
be worth ditching class for embedded data just to help uptake.

2. The class space is already populated with lots of ill-thought-out
CSS identifiers. This means POSH formats have to attempt crude forms
of namespacing (e.g. picking a uniquely-named root element) to try and
not collide with existing markup. That works for @class="fn" say, but
it's easy to collide with @class="email". Microdata separates out the
important stuff.

3. Related to 2, microdata extraction is possible without having to be
profile-aware, so for instance microdata can be converted to JSON
without knowledge of the vocabulary used.

4. Microdata features some structures like @itemref that help combine
disparate data across a document into one Microdata element, which in
Microformats would need the slightly hacky rel-include structures that
frankly I don't think anyone has been completely happy with.

5. Microdata allows locally-scoped typing using the @itemtype property
and a URL, while a POSH format can only do something similar with a
document-level @profile.

6. Microdata defines an API for DOM access to Microdata that allows
scripts to deal with Microdata-embedded data when doing the same with
Microformats involves some fairly heavy DOM parsing.


Well written. Unlike yourself, I agree with all of the above :)


The arguments against Microdata are basically that it's complex, huge,
obviously isn't based on any existent markup in the wild, and really
doesn't look like an obvious core element of HTML5 so it's weird that
it's included in the same spec.


Well, it's not in W3C's version of HTML5, they published it as a separate  
spec (which is strange, IMO). Regardless of what spec it is in, it still  
works just the same, so that's OK.


--
Philip Jägenstedt
Core Developer
Opera Software

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

Re: [uf-discuss] re: HTML5 support

[Ciaran McNulty]

On Tue, Jul 20, 2010 at 5:05 AM, Angelo Gladding  wrote:
> Can an enlightened soul describe in which ways microdata is actually
> superior to profiled poshformats?

To me it's not a question of Microdata vs POSH, it's more like
Microdata vs class attributes where both are methods that can be used
in POSH style data embedding.

The main arguments (and I present these without necessarily agreeing!)
seem to be:

1. Class is ingrained as a CSS hook mechanism. Most people on this
list are fine with class being used for other purposes, but despite
that the argument comes up incredibly often that using class is
somehow a 'hack'. Microdata overcomes that, so right or wrong, it may
be worth ditching class for embedded data just to help uptake.

2. The class space is already populated with lots of ill-thought-out
CSS identifiers. This means POSH formats have to attempt crude forms
of namespacing (e.g. picking a uniquely-named root element) to try and
not collide with existing markup. That works for @class="fn" say, but
it's easy to collide with @class="email". Microdata separates out the
important stuff.

3. Related to 2, microdata extraction is possible without having to be
profile-aware, so for instance microdata can be converted to JSON
without knowledge of the vocabulary used.

4. Microdata features some structures like @itemref that help combine
disparate data across a document into one Microdata element, which in
Microformats would need the slightly hacky rel-include structures that
frankly I don't think anyone has been completely happy with.

5. Microdata allows locally-scoped typing using the @itemtype property
and a URL, while a POSH format can only do something similar with a
document-level @profile.

6. Microdata defines an API for DOM access to Microdata that allows
scripts to deal with Microdata-embedded data when doing the same with
Microformats involves some fairly heavy DOM parsing.

The arguments against Microdata are basically that it's complex, huge,
obviously isn't based on any existent markup in the wild, and really
doesn't look like an obvious core element of HTML5 so it's weird that
it's included in the same spec.

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

Re: [uf-discuss] re: HTML5 support

[Philip Jägenstedt]

On Tue, 20 Jul 2010 06:05:06 +0200, Angelo Gladding   
wrote:



Could it be said that microdata intends to do to Microformat syntax
what HTML5 did to HTML4 syntax rules in the sense that parsing is
unambiguous and easier to validate normativity?


Yes, more or less. Of course vocabulary-specific rules can only be checked  
by a specialized validator, but checking the actual structure (key-value  
pairs) is something you get "for free". Also, I expect automatic  
validation of date-formats would be appreciated.



Can an enlightened soul describe in which ways microdata is actually
superior to profiled poshformats?


Microdata should be compared to the class attributes and the various  
patterns that microformats use, not any specific vocabulary. The main  
benefit is that parsing becomes well-defined and simple. That's why it's  
possible to define a JavaScript API for accessing microdata items on a  
page, which makes the data useful to the page itself, not only external  
scrapers. It also makes it feasible to make browser features like "add to  
address book" or "add to calendar", which really isn't really practical  
with microformats when the data is hidden in class attributes together  
with everything else.



Might a "humans first, machines second" CJKV internationalization of
`n` optimization be to analyze the contents of the `fn`'s @lang and
inner text and use either or both to better determine name order?


The main problem with this is that due to lazy copy-pasting, lang="en" is  
often used even when the language isn't English. Also, in the case of e.g.  
Facebook, lang="en" would be correct for the page itself, but people's  
names aren't in English anyway. The only way to get it right is to ask the  
user both for the full name, given name and family name, something I  
haven't ever seen. The most practical solution is to not guess at all, and  
I don't know of any negative effects of this.


--
Philip Jägenstedt
Core Developer
Opera Software

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

Re: [uf-discuss] re: HTML5 support

[Martin McEvoy]

 On 20/07/2010 03:57, Oli Studholme wrote:

Hey Scott,

On Tue, Jul 20, 2010 at 9:34 AM, Scott Reynen  wrote:


Making specific cases easier is the whole point of microformats, but it's not 
at all the point of microdata.

“Making specific cases easier is the whole point of the class
attribute, but it's not at all the point of microdata”

Microdata — and semantic class names plus posh coding patterns for
current microformats — are the method; a means to an end. Microdata
vocabularies use microdata to express semantics, just as microformats
use the class attribute etc to express semantics. Microformats are a
little more concise in general (cough, datetimes ;-) compared to the
same vocabulary in microdata (@class is shorter than @itemprop by 4
characters, @property is optional whereas @itemtype is required etc),
but the differences are not so great, and any class-based microformat
can be written using microdata.


Im sorry but you cannot express *microformats* in microdata if you do, 
its cute, but It isn't a microformat because microformats *only* use  
class names, and a few choice rel-values.  If you move a microformat 
away from @class its no longer a microformat and shouldn't be described 
as such (we are a bit fussy about that :P).


This is why when someone starts talking about a "new microformats" or 
"microformats done better" the first thing I ask myself is "does it use 
semantic class names?" ... no well its not a new microformat or 
microformats done better.


Well the *good* news is HTML5 already supports microformats without 
adding any attributes at all (Yay!)  that is until someone marks 
@class as obsolete!! ... joke.


Best wishes.

--
Martin McEvoy

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

Re: [uf-discuss] re: HTML5 support

[Angelo Gladding]

Could it be said that microdata intends to do to Microformat syntax
what HTML5 did to HTML4 syntax rules in the sense that parsing is
unambiguous and easier to validate normativity?

Can an enlightened soul describe in which ways microdata is actually
superior to profiled poshformats?

- - -

Might a "humans first, machines second" CJKV internationalization of
`n` optimization be to analyze the contents of the `fn`'s @lang and
inner text and use either or both to better determine name order?

e.g.

Angelo Gladding

{
  "hCard": [
{
  "hcard": {
"fn": "Angelo Gladding",
"n": {
  "n": {
"family-name": [
  "Gladding"
],
"given-name": [
  "Angelo"
]
  }
}
  }
}
  ]
}

where
アンジェロ == anjero (Angelo)
グラッディング == guraddingu (Gladding)

グラッディング　アンジェロ


グラッディング　アンジェロ


グラッディング　アンジェロ

{
  "hCard": [
{
  "hcard": {
"fn": 
"\u30b0\u30e9\u30c3\u30c7\u30a3\u30f3\u30b0\u3000\u30a2\u30f3\u30b8\u30a7\u30ed",
"n": {
  "n": {
"family-name": [
  "\u30b0\u30e9\u30c3\u30c7\u30a3\u30f3\u30b0"
],
"given-name": [
  "\u30a2\u30f3\u30b8\u30a7\u30ed"
]
  }
}
  }
}
  ]
}

i.e.

Splitting on \u3000 (CJKV space), perform `n` optimization in reverse
when the `fn` element/ancestor matches @lang(zh|ja|ko|vi) or the first
character of the text content lies in one of the following Unicode
character ranges:

U+4E00–U+9FBF (Kanji)
U+3040–U+309F (Hiragana)
U+30A0–U+30FF (Katakana)
http://en.wikipedia.org/wiki/Japanese_writing_system

... Chinese ... Korean ... Vietnamese ... *i18n expert needed*

While this requires what I believe to be an uncommon usage of a space
delimeter among CJK names it could be an easy hack for a user of Site
X, assuming Site X does not explicitly define `n` properties, to
implement upon failed validation without necessitating code
modification on Site X's end.

-- 
Angelo Gladding
ang...@gladding.name

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

Re: [uf-discuss] re: HTML5 support

[Oli Studholme]

Hey Scott,

On Tue, Jul 20, 2010 at 9:34 AM, Scott Reynen  wrote:

>> Microdata doesn't go out of its way to be compatible with existing RDF 
>> vocabularies
>
> Maybe not specific vocabularies (that's kind of my point), but RDF itself is 
> clearly a major consideration.  There's a whole section on it:
>
> http://www.w3.org/TR/microdata/#rdf

No. There’s a sub-sub-section on converting to RDF, just as there are
for converting to JSON and Atom. That’s not a design goal, it’s
specified interoperability. There are also sub-sub-sections on vcard,
vevent and licensing vocabularies, so by the same logic these are also
major considerations (again no, they’re sample vocabularies).

> It's no surprise that general purpose formats like microdata don't express 
> specific vocabularies as succinctly as microformats.

You’re not doing a lot of hCalendar formats I take it? ;-)

> I'd argue it is a bad idea in microdata, but not in microformats, because of 
> the very distinction I'm trying to draw between the two.

As far as microdata goes it’s irrelevant — that’s something decided by
the *vocabulary* author. Adding it isn’t a bad idea if the vocabulary
author thinks the shortcut has more good than bad points.

> Making specific cases easier is the whole point of microformats, but it's not 
> at all the point of microdata.

“Making specific cases easier is the whole point of the class
attribute, but it's not at all the point of microdata”

Microdata — and semantic class names plus posh coding patterns for
current microformats — are the method; a means to an end. Microdata
vocabularies use microdata to express semantics, just as microformats
use the class attribute etc to express semantics. Microformats are a
little more concise in general (cough, datetimes ;-) compared to the
same vocabulary in microdata (@class is shorter than @itemprop by 4
characters, @property is optional whereas @itemtype is required etc),
but the differences are not so great, and any class-based microformat
can be written using microdata.

peace - oli

PS @Philip the reasons for n optimisation are as in the wiki; a
combination of putting authors first (shortcut for western-style
“given-name family-name” names), and accommodating mistakes in the
original RFC. I guess there was the expectation that hCard would
mainly be used with western-style names, a lack of knowledge of
Vietnamese, Chinese and other names that would be incorrectly
classified by this optimisation, and/or this shortcut was valued above
i18n issues (it was made back in 2005 after all).

I’d originally thought of it as just an edge case in Japanese, but
reading about Vietnamese, Chinese and Korean names I’m starting to
feel this is a serious i18n issue. I wonder what Tantek’s view, and
the view of whoever else is working on hCard 1.0.1, is. I wonder if it
will be perceived to be as serious as the a11y issues the abbr time
pattern had…

Aah just found
http://microformats.org/wiki/hcard-issues-resolved#fn-opt-i18n
and it seems not. I guess there’s the assumption that east asian pages
specify their language, which seems somewhat disconnected from reality
:/

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

Re: [uf-discuss] re: HTML5 support

[Scott Reynen]

On Jul 19, 2010, at 2:31 AM, Philip Jägenstedt wrote:

>>> Out of curiosity what do you perceive are the different problems that
>>> microformats and microdata are trying to solve?
>> 
>> Microformats aim to "solve a specific problem."  Microdata aims to be 
>> compatible with RDF, which demands more generic semantics.
> 
> Microdata doesn't go out of its way to be compatible with existing RDF 
> vocabularies

Maybe not specific vocabularies (that's kind of my point), but RDF itself is 
clearly a major consideration.  There's a whole section on it:

http://www.w3.org/TR/microdata/#rdf

> In any event there's very little "RDFness" over the syntax itself, the model 
> is key-values, not triples.

It may not translate *well* to RDF, but I disagree that such translation isn't 
a goal.  The syntax isn't particularly important, though.  RDF is simply my 
sloppy shorthand for general purpose semantics.  Microformats, unlike both RDF 
and microdata, are explicitly not intended to be general purpose.  The 
microdata spec itself doesn't even mention specific vocabularies, whereas 
microformats are nothing *but* specific vocabularies.  It's no surprise that 
general purpose formats like microdata don't express specific vocabularies as 
succinctly as microformats.  It's also no surprise that microformats don't 
cover as much variety of data as general purpose formats.

>> Because of this, I doubt you'll ever see something like n optimization in 
>> microdata.
> 
> This isn't a difference between microformats and microdata. The microdata 
> vocabulary *had* the 'n' optimization, but it was removed after I showed that 
> it didn't work for e.g. Chinese or Vietnamese.

Well, so much for that prediction.  Still, the removal suggests to me that it 
*is* a significant difference:

> I tried to learn from this community why it isn't a bad idea, but there 
> wasn't much useful feedback.

I'd argue it is a bad idea in microdata, but not in microformats, because of 
the very distinction I'm trying to draw between the two.

n optimization isn't required.  It's a handy shorthand in some specific cases, 
but shouldn't be used universally, as it does't make sense everywhere.  hCard 
can handle Chinese names just fine with explicit given-name and family-name 
properties.  Nothing about n optimization makes this more difficult; n 
optimization only makes specific cases easier.  Making specific cases easier is 
the whole point of microformats, but it's not at all the point of microdata.

Peace,
Scott


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

Re: [uf-discuss] re: HTML5 support

[Philip Jägenstedt]

On Sun, 18 Jul 2010 18:10:37 +0200, Scott Reynen   
wrote:



On Jul 18, 2010, at 6:38 AM, Oli Studholme wrote:


Out of curiosity what do you perceive are the different problems that
microformats and microdata are trying to solve?


Microformats aim to "solve a specific problem."  Microdata aims to be  
compatible with RDF, which demands more generic semantics.


Microdata doesn't go out of its way to be compatible with existing RDF  
vocabularies, in fact I'd argue that the RDF extraction algorithm creates  
some pretty ugly URIs that anyone who actually likes RDF would frown upon  
and not want to use. In any event there's very little "RDFness" over the  
syntax itself, the model is key-values, not triples.


Because of this, I doubt you'll ever see something like n optimization  
in microdata.  You've suggested that's a good thing because n  
optimization doesn't make sense in all cases, but that's the crux of it:  
microformats aren't trying to make sense in all cases, while microdata  
is.  n optimization isn't a good thing or a bad thing; it's simply a  
reflection of different goals.


This isn't a difference between microformats and microdata. The microdata  
vocabulary *had* the 'n' optimization, but it was removed after I showed  
that it didn't work for e.g. Chinese or Vietnamese. I tried to learn from  
this community why it isn't a bad idea, but there wasn't much useful  
feedback. It really should be removed from microformats too, but that's  
probably too late.


--
Philip Jägenstedt
Core Developer
Opera Software

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

Re: [uf-discuss] re: HTML5 support

[Oli Studholme]

Hey Scott,

thanks for your reply.

On Mon, Jul 19, 2010 at 1:10 AM, Scott Reynen  wrote:

> Microformats aim to "solve a specific problem."  Microdata aims to be 
> compatible with RDF, which demands more generic semantics.  Because of this, 
> I doubt you'll ever see something like n optimization in microdata.  You've 
> suggested that's a good thing because n optimization doesn't make sense in 
> all cases, but that's the crux of it: microformats aren't trying to make 
> sense in all cases, while microdata is.  n optimization isn't a good thing or 
> a bad thing; it's simply a reflection of different goals.

I disagree. The purpose of microdata is to “annotate content with
specific machine-readable labels, e.g. to allow generic scripts to
provide services that are customised to the page”. This is also a
pretty good description of how @class is used in microformats, and I
think that’s a good metaphor. I think you should be comparing
microformats with microdata *vocabularies*, which also aim to solve a
specific problem. Microdata is just a method by which to do this.
While it’s possible to convert microdata into RDFa (along with JSON
and Atom), compatibility with RDF is not the aim of microdata — if
anything it seems to be “provide a simple mechanism to semantically
extend HTML5 to keep ppl who think this is important happy” :)

The n optimisation was actually in the microdata vcard spec, but Hixie
removed it after deciding it was “magic”. While I can understand the
reasons, I think it’d be less confusing/easier if the vcard vocabulary
either removed all reference to hcard (e.g. used a
non-microformats.org itemtype URL), or mapped hCard exactly. I’m
hoping that once hCard 1.0.1 is finished one or both of these things
might happen.

As for using microdata, if you’re using simple microformats (just
fn+url hcards for example) maybe it is too wordy a method. But
personally I generally can’t use that optimisation (for example:
http://www.cie.mie-u.ac.jp/en/tri-u/2006/committee.html ), so I’m
interested in microdata vocabularies for microformats, or the generic
way of representing microformats in microdata that Tantek mentioned a
year ago.

> Maybe you could clarify what specifically you see as negativity toward 
> microdata?

maybe I’m just reading too much into it after talking about
microformats and microdata with RDF ppl :D

peace - oli

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

Re: [uf-discuss] re: HTML5 support

[Oli Studholme]

Hey Martin,

On Wed, Jul 14, 2010 at 12:06 PM, Oli Studholme
 wrote:
>> Microdata vcard example from
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#vcard
>>
>> http://microformats.org/profile/hcard";>
>>        
>>                
>>                        George
>>                        Washington
>>                
>>        
>> 
>
> This is equivalent to
>
> http://microformats.org/profile/hcard";>
>       
>              George
>              Washington
>       
> 

I’m sorry but I misunderstood/misread the microdata vcard spec (I
didn’t realise that n was a nested item), and my example is wrong. It
should be longer not shorter :)

http://microformats.org/profile/hcard";>
       
               
                       George
                       Washington
               
       


So for a non-Western name one extra wrapper element, but for a name
with n optimisation three extra wrapper elements.

peace - oli

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

Re: [uf-discuss] re: HTML5 support

[Scott Reynen]

On Jul 18, 2010, at 6:38 AM, Oli Studholme wrote:

>> I'd suggest removing the entire vocabulary-specific section altogether.  As 
>> mentioned in the same page, microdata is aiming to solve a different problem 
>> than microformats, so it's misleading to suggest specific vocabularies are 
>> actually alternatives to specific microformats by talking about them 
>> vis-a-vis microformats.
> 
> I’m sorry, but what text are you referring to?

This is what I'm referring to as the "vocabulary-specific section":

http://microformats.org/wiki/microdata#microdata_vocabularies

This is what I'm referring to as "mentioned in the same page, microdata is 
aiming to solve a different problem":

http://microformats.org/wiki/microdata#potential

> Out of curiosity what do you perceive are the different problems that
> microformats and microdata are trying to solve?

Microformats aim to "solve a specific problem."  Microdata aims to be 
compatible with RDF, which demands more generic semantics.  Because of this, I 
doubt you'll ever see something like n optimization in microdata.  You've 
suggested that's a good thing because n optimization doesn't make sense in all 
cases, but that's the crux of it: microformats aren't trying to make sense in 
all cases, while microdata is.  n optimization isn't a good thing or a bad 
thing; it's simply a reflection of different goals.

> I personally see microformats as a grass-roots movement that uses the
> tools available to extend HTML with extra semantics. Currently this is
> accomplished using @class, @rel etc. I see microdata as a new tool in
> HTML5 that would also be suitable for using with microformats, so I’m
> wondering what’s up with all the negativity directed toward microdata
> in these replies.

Maybe you could clarify what specifically you see as negativity toward 
microdata?  I don't see microdata and microformats having different goals as a 
bad thing for either.  Different goals are good.

Peace,
Scott


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

Re: [uf-discuss] re: HTML5 support

[Oli Studholme]

Hey All,

re: Martin’s earlier email

On Wed, Jul 14, 2010 at 10:45 AM, Martin McEvoy
 wrote:
> 
> George Washington
> 

I think the issue you had with the microdata equivalent was
brevity/simplicity, correct? While the ‘n’ class optimisation isn’t in
the microdata vocabulary, and I’ve already covered how for non-Western
style names this doesn’t apply (and is potentially harmful), I forgot
about the profile attribute:
http://microformats.org/wiki/hcard#Profile

The difference is in microdata a profile (vocabulary) link is required
via @itemtype, whereas it’s a “_should_” in microformats. If we add a
profile to my previous non-English example results in a draw for me in
the simplicity stakes:

http://microformats.org/profile/hcard";>
…

   
   スタッドホルム・
   オリ
   


http://microformats.org/profile/hcard"; lang="ja">
   
   スタッドホルム・
   オリ
   


Of course if you can use implied ‘n’ optimisation microformats are
definitely simpler, but the difference is less pronounced when using
@profile:

http://microformats.org/profile/hcard";>
…

   Oli Studholme


http://microformats.org/profile/hcard"; lang="ja">
   Oli
Studholme


Of course, no one actually uses @profile with microformats, so it’s
probably a moot point :D

Finally thank you for pointing out the nested fn and n itemprops in
the spec example which should be in the same itemprop. I filed a bug:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10159


On Wed, Jul 14, 2010 at 1:09 PM, Scott Reynen  wrote:

> I'd suggest removing the entire vocabulary-specific section altogether.  As 
> mentioned in the same page, microdata is aiming to solve a different problem 
> than microformats, so it's misleading to suggest specific vocabularies are 
> actually alternatives to specific microformats by talking about them 
> vis-a-vis microformats.

I’m sorry, but what text are you referring to? What I see is:
“microdata is an extension to HTML5 that provides another way to embed
microformats and poshformats vocabularies”

> Put another way, that section violates DRY.  Because microdata is aiming to 
> solve a different problem, *no* microdata vocabulary could possibly be 
> recommended in place of a specific microformat, so it's redundant to go into 
> the ways in which a specific microdata vocabulary goes against microformat 
> principles, principles it's not even attempting to follow.

Out of curiosity what do you perceive are the different problems that
microformats and microdata are trying to solve?

I personally see microformats as a grass-roots movement that uses the
tools available to extend HTML with extra semantics. Currently this is
accomplished using @class, @rel etc. I see microdata as a new tool in
HTML5 that would also be suitable for using with microformats, so I’m
wondering what’s up with all the negativity directed toward microdata
in these replies.


@Tantek:

It seems the current inclusion of vcard and vevent vocabularies in the
HTML5 spec is something of a problem (at least based on the IMO
incorrect comments in the wiki I’ve pointed out above), so I wonder
how is progress going on the 1.0.1 versions that Hixie said he’d be
happy to link to as normative versions?
Ref: http://krijnhoetmer.nl/irc-logs/whatwg/20090717#l-335

According to Hixie the vcard/vevent vocabularies are in the spec as
examples of how to write a microdata vocabulary, so could presumably
be changed with something else (“the vcard one is basically a proof of
concept to show that it is possible to design a vocabulary in very
little time and to show how to write a spec for one”)
ref: http://krijnhoetmer.nl/irc-logs/whatwg/20100713#l-884

Finally, I wonder how I can assist in the documentation of how to use
any microformat via microdata?

ref: http://krijnhoetmer.nl/irc-logs/whatwg/20090717#l-437
# [10:36]  tantek: will current Microformats be released in
Microdata format at some stage?
# [10:37]  boblet - doubtful. but will likely happen is that
microformats.org will document how to use *any* microformat
generically using microdata syntax. watch this page for updates:
http://microformats.org/wiki/html5

peace - oli
@boblet

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

Re: [uf-discuss] re: HTML5 support

[Scott Reynen]

On Jul 13, 2010, at 8:14 PM, Oli Studholme wrote:

> Suggested edit on
> http://microformats.org/wiki/microdata#microdata_vCard_vocabulary
> Avoid the "microdata vCard vocabulary" as in many ways it is an
> out-of-date fork/snapshot of hCard, even though portions of it appear
> to based directly on the vCard RFC. as well.
> →
> Avoid the "microdata vCard vocabulary" as it is based directly on the vCard 
> RFC.

I'd suggest removing the entire vocabulary-specific section altogether.  As 
mentioned in the same page, microdata is aiming to solve a different problem 
than microformats, so it's misleading to suggest specific vocabularies are 
actually alternatives to specific microformats by talking about them vis-a-vis 
microformats.

Put another way, that section violates DRY.  Because microdata is aiming to 
solve a different problem, *no* microdata vocabulary could possibly be 
recommended in place of a specific microformat, so it's redundant to go into 
the ways in which a specific microdata vocabulary goes against microformat 
principles, principles it's not even attempting to follow.

Peace,
Scott


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

Re: [uf-discuss] re: HTML5 support

[Oli Studholme]

Hey Martin,

On Wed, Jul 14, 2010 at 10:45 AM, Martin McEvoy
 wrote:
> On 13/07/2010 17:59, Oli Studholme wrote:
>> But how could microdata possibly disappear now that Google supports it? ;)
>
> Because Microdata is far to obtrusive to be practical in the "real world"
> for example
>
> Microdata vcard example from
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#vcard
>
> http://microformats.org/profile/hcard";>
>        
>                
>                        George
>                        Washington
>                
>        
> 

This is equivalent to

http://microformats.org/profile/hcard";>
   
  George
  Washington
   


> from a commercial and practical point of view, microdata is definitely not
> intended to be for "humans first" .

I think it would be more accurate to say RFC2426 is not intended to be
“humans first” ;-) for better or worse vCard doesn’t contain implied
“n” optimisation.

> Anyway believe what you like, microdata needs a *lot* of work before it can
> ever be considered as  "micro" as far as I can see, at the moment It just
> confuses people into using an unnecessary semantic.

Well, to use a non-English example:



スタッドホルム・
オリ



http://microformats.org/profile/hcard"; lang="ja">

スタッドホルム・
オリ



These seem pretty equivalent to me, with the main difference in length
being the itemtype URL. However there are advantages to using URLs for
specifying a vocabulary. Keep in mind the implied “n” optimisation is
arguably potentially dangerous e.g. for a social app that only
collects the user’s name, rather than two separate fields for given
and family names, and then displays this as an hCard. While some
languages that have family-name given-name order don’t use a space
separator (CJK), a quick look at http://twitter.com/boblet shows one
incorrect optimisation for my friend Channy: “윤석찬(Channy Yun)”. As you
can imagine this doesn’t optimise well. I’d look for more but it seems
Twitter’s profile page vcards are completely borked :)

I agree that for marking up a person with their name and URL — if you
can use implied “n” optimisation — microformats is superfast. However
I find I often use hCard for more data than just that, to the extent
that writing them without snippets becomes tiring. And if you’re
making snippets, there’s little difference.

HTH

peace - oli

PS just saw your reply (I can’t keep up! :) Yeah I’ve definitely
wanted an equivalent to itemref for microformats, and hadn’t come
across the include pattern before. thanks!

> in a way that can help microformats *and* be 100% compatible with the way 
> microformats exist now

I don’t think compatibility is so important. Microformats, microdata
and RDFa all target the same basic problem space but each has it’s
strengths and weaknesses. different ideas help each technology improve
(RDFa 1.1 moving towards microformats’ simplicity for example).
Finally (I perceive) µF as an elegant hack to graft new semantics onto
HTML using the tools available; class, rel, rev, profile and coding
patterns. With the changed toolset in HTML5 (including no rev or
profile attributes) it makes sense to reassess methods, and I’m
looking at microdata and RDFa for that reason.

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

Re: [uf-discuss] re: HTML5 support

[Martin McEvoy]

 Oli Please don't get me wrong microdata does offer some interesting 
potential as far as microformats are concerned, It just needs looking at 
with "new eyes" and in a way that can help microformats *and* be 100% 
compatible with the way microformats exist now.
There are a couple of attributes that could really be useful to 
microformats, the itemscope attribute because its opaque, and itemref 
which very similar to the include pattern but better because it would 
allow an author to reference whole blocks of data not just a single 
property.


example, you could have the following markup somewhere in a page:


Alfred Hitchcock


and add different parts of a page say in the footer


1600 Amphitheatre Parkway 
Building 43, Second Floor 
Mountain View,
CA
94043


I don't see any problem in microformats adopting only the parts of 
microdata that are useful to microformats, there are probably others who 
will disagree with that though ;-)


Best wishes.

Martin


On 14/07/2010 02:45, Martin McEvoy wrote:

 Hello Oli ...

On 13/07/2010 17:59, Oli Studholme wrote:
On Tue, Jul 13, 2010 at 5:13 AM, Martin 
McEvoy  wrote
I wouldnt really be surprised to see microdata disappear all 
together(but

that's just my thought)
But how could microdata possibly disappear now that Google supports 
it? ;)


Because Microdata is far to obtrusive to be practical in the "real 
world" for example


Microdata vcard example from 
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#vcard


http://microformats.org/profile/hcard";>


George
Washington




8 lines of code which would parse as:

BEGIN:VCARD
PROFILE:VCARD
VERSION:3.0
SOURCE:document's address
FN:George Washington
N:Washington;George;;;
END:VCARD

great you would think, now try that using microformats, example from 
http://yiid.cc/3GI2



George Washington


3 lines of code which parses as:

BEGIN:VCARD
SOURCE:document's address
NAME:document's title
VERSION:3.0
N;CHARSET=UTF-8:Washington;George;;;
FN;CHARSET=UTF-8:George Washington
END:VCARD

from a commercial and practical point of view, microdata is definitely 
not intended to be for "humans first" .


Anyway believe what you like, microdata needs a *lot* of work before 
it can ever be considered as  "micro" as far as I can see, at the 
moment It just confuses people into using an unnecessary semantic.


Best wishes




--
Martin McEvoy

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

Re: [uf-discuss] re: HTML5 support

[Oli Studholme]

Hey Tantek,

>From IRC:

# [20:52]  hey Hixie, can you give me more details about the
microdata vcard vocab being based on vcard not “an out-of-date fork of
hcard”?
# [20:54]  i just went down the vcard spec and mapped it
directly to microdata
# [20:54]  i had originally made some minor changes to match
hcard in places, but i've since removed those
# [20:56]  Hixie: was that the fn magic? any other hcard ->
vcard reversions?
# [20:56]  i think the only bit was the stuff with FN, yeah
# [20:57]  everything else is just a straight mapping of the vcard spec
# [20:57]  i did use the hcard names for the bits of vcard that
needed splitting into multiple fields, but just to make sure the
terminology was consistent, it's not "forked from hcard" or anything
…
# [20:58]  the whole point of microdata is that people can use
whatever vocabularies they like; the vcard one is basically a proof of
concept to show that it is possible to design a vocabulary in very
little time and to show how to write a spec for one

http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#vcard
“The following are the type's defined property names. They are based
on the vocabulary defined in the vCard specification and its
extensions, where more information on how to interpret the values can
be found. [RFC2426] [RFC4770]”

Suggested edit on
http://microformats.org/wiki/microdata#microdata_vCard_vocabulary
Avoid the "microdata vCard vocabulary" as in many ways it is an
out-of-date fork/snapshot of hCard, even though portions of it appear
to based directly on the vCard RFC. as well.
→
Avoid the "microdata vCard vocabulary" as it is based directly on the vCard RFC.

(Plus the same for vEvent)


Regarding rel-* microformats:

# rel-nofollow

Microformats:
“By adding rel="nofollow" to a hyperlink, a page indicates that the
destination of that hyperlink should not be afforded any additional
weight or ranking by user agents which perform link analysis upon web
pages (e.g. search engines). Typical use cases include links created
by 3rd party commenters on blogs, or links the author wishes to point
to, but avoid endorsing.”

HTML5:
“The nofollow keyword indicates that the link is not endorsed by the
original author or publisher of the page, or that the link to the
referenced document was included primarily because of a commercial
relationship between people affiliated with the two pages.”

# rel-license

Microformats:
“By adding rel="license" to a hyperlink, a page indicates that the
destination of that hyperlink is a license for the current page.”

HTML5:
“The license keyword indicates that the referenced document provides
the copyright license terms under which the main content of the
current document is provided.”

Out of curiosity what are the perceived incompatibilities in these two
examples that prevent them from being listed under
http://microformats.org/wiki/html5#Current_microformat_compatibility ?

peace - oli

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

Re: [uf-discuss] re: HTML5 support

[Martin McEvoy]

 Hello Oli ...

On 13/07/2010 17:59, Oli Studholme wrote:

On Tue, Jul 13, 2010 at 5:13 AM, Martin McEvoy  wrote

I wouldnt really be surprised to see microdata disappear all together(but
that's just my thought)

But how could microdata possibly disappear now that Google supports it? ;)


Because Microdata is far to obtrusive to be practical in the "real 
world" for example


Microdata vcard example from 
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#vcard


http://microformats.org/profile/hcard";>


George
Washington




8 lines of code which would parse as:

BEGIN:VCARD
PROFILE:VCARD
VERSION:3.0
SOURCE:document's address
FN:George Washington
N:Washington;George;;;
END:VCARD

great you would think, now try that using microformats, example from 
http://yiid.cc/3GI2



George Washington


3 lines of code which parses as:

BEGIN:VCARD
SOURCE:document's address
NAME:document's title
VERSION:3.0
N;CHARSET=UTF-8:Washington;George;;;
FN;CHARSET=UTF-8:George Washington
END:VCARD

from a commercial and practical point of view, microdata is definitely 
not intended to be for "humans first" .


Anyway believe what you like, microdata needs a *lot* of work before it 
can ever be considered as  "micro" as far as I can see, at the moment It 
just confuses people into using an unnecessary semantic.


Best wishes

--
Martin McEvoy

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

Re: [uf-discuss] re: HTML5 support

[Oli Studholme]

Hey all,

Thanks for your replies

On Tue, Jul 13, 2010 at 1:31 AM, Tantek Celik  wrote:

> Please don't update the pages just based on a "guess" that the warnings are 
> no longer relevant, and revert accordingly.

I’d revert the warnings, but it appears you’ve moved the content to
the wiki/microdata page, so I’m assuming the current text is as
desired. I asked @hixie about the warning and was told that the vCard
vocabulary had been based on hCard (I guess this is the fork your
comment referred to), but was now based directly on vCard. I also
asked @phae and @adactio about the warning, and was encouraged to make
changes. I’m not able to find a corroborating svn log entry — I’ll ask
@hixie for more info.

> In general, the latest, most accurate work on microformats (both class 
> vocabularies and rel values), is on the microformats wiki, not the HTML5 
> spec, and thus you should refer to the microformats wiki spec pages as 
> canonical.

I understand. I’d assumed the page was out of date due to the other
errors I fixed, and the lack of reply to my comment about timezone
validation from February. I’ll email the list in future. Also thank
you for the much clearer guidance on wiki/microdata.


On Tue, Jul 13, 2010 at 5:13 AM, Martin McEvoy  wrote:

> microdata does however exist as a separate specification [2] but is just
> "attributes" and as far as I know, microdata vCard and vEvent no longer
> exists as part of the microdata specification do they?.

They’ve been removed due to “politics”. They’re available via the
WHATWG spec as referenced in my email, and now in the wiki/microdata
page (thanks Tantek).

> I wouldnt really be surprised to see microdata disappear all together(but
> that's just my thought)

But how could microdata possibly disappear now that Google supports it? ;)


Finally thanks for the clarification Philip

peace - oli

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

Re: [uf-discuss] re: HTML5 support

[Philip Jägenstedt]

On Mon, 12 Jul 2010 17:27:52 +0200, Oli Studholme  
 wrote:



Finally, what was the upshoot of this email about the “magic” in fn?
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024881.html


It was dropped in  
 with the  
commit message "Remove the magic from the vCard vocabulary, since the  
magic doesn't really work." It should be removed from the upstream  
vocabulary too, but I have little hope of that happening.


--
Philip Jägenstedt
Core Developer
Opera Software

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

Re: [uf-discuss] re: HTML5 support

[Martin McEvoy]

 On 12/07/2010 17:31, Tantek Celik wrote:

If you can verify the changes made in microdata are consistent with hCard etc 
(rather than a fork), and cite the specific changes, then it makes sense to 
make updates.


It may be relevant to note that microdata is no longer part of the HTML5 
core [1] .
microdata does however exist as a separate specification [2] but is just 
"attributes" and as far as I know, microdata vCard and vEvent no longer 
exists as part of the microdata specification do they?.
I wouldnt really be surprised to see microdata disappear all 
together(but that's just my thought)


Best wishes

[1] http://www.w3.org/TR/html5/
[2] http://www.w3.org/TR/microdata/

--
Martin McEvoy

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

Re: [uf-discuss] re: HTML5 support

[Tantek Celik]

Hi Oli,

In short, the warnings are still relevant.

Please don't update the pages just based on a "guess" that the warnings are no 
longer relevant, and revert accordingly. 

If you can verify the changes made in microdata are consistent with hCard etc 
(rather than a fork), and cite the specific changes, then it makes sense to 
make updates.

Regarding the rel-values - the latest correct definitions are still on the 
microformats wiki.

For example the HTML5 definition of rel-tag mistakenly always applies it to the 
whole page which is incorrect.

The microformats.org/wiki/rel-tag spec and implementations commonly apply it to 
parts of a page like blog posts (hAtom, Technorati, IceRocket), or 
contacts/events/items (hCard, hCalendar, hReview, hListing, hProduct).

In general, the latest, most accurate work on microformats (both class 
vocabularies and rel values), is on the microformats wiki, not the HTML5 spec, 
and thus you should refer to the microformats wiki spec pages as canonical.

Thanks,

Tantek


-Original Message-
From: Oli Studholme 
Sender: microformats-discuss-boun...@microformats.org
Date: Tue, 13 Jul 2010 00:27:52 
To: 
Reply-To: Microformats Discuss 
Subject: [uf-discuss] re: HTML5 support

Hey all,

I’ve got a few questions about using microformats in HTML5:

Back on 14 October 2009, Tantek made the following additions to
http://microformats.org/wiki/html5

===
microdata vocabularies

microdata vCard - use hCard instead, taking into account the hCard FAQ
and resolved+closed issues. hCard 1.0.1 (under development) is
incorporating these errata. Avoid the "microdata vCard" vocabulary as
it is an out-of-date fork/snapshot of hCard.
microdata vEvent - use hCalendar instead, taking into account the
hCalendar FAQ and resolved+closed issues. hCalendar 1.0.1 is
incorporating these errata. Avoid the "microdata vEvent" vocabulary,
as it is an out-of-date fork/snapshot of hCalendar's vevent root class
name and applicable properties.
===

I’m assuming this was when Microdata vcard and vevent specs were
based on hCard and hCalendar. They’re now based on the original RFCs,
so I guess these warnings are no longer relevant, and have updated the
page. If they are still relevant (Tantek?) please let me know the
situation and I’ll update as required or roll back.

Ref:
* Microdata vcard:
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#vcard
* Microdata vevent:
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#vevent


I’m also wondering if someone can explain the “encourage HTML5 to drop
their vocabulary and use µF vocabulary instead” comments on the
brainstorming pages linked to from:
http://microformats.org/wiki/html5#Requests
Again if these are no longer accurate I’m happy to update them.


Under Current microformat compatibility
http://microformats.org/wiki/html5#Current_microformat_compatibility
only hCard and XFN are listed as compatible. I’m wondering if I should
also add these specifications too:
* XOXO
* rel-nofollow (defined in HTML5 spec)
* rel-license (defined in HTML5 spec)
* rel-tag (defined in HTML5 spec)
(the rel values are defined on
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html
)

There’s a bunch more draft specifications that look to be compatible,
and there’s also a way to add extra rel values to the HTML5 spec:
http://wiki.whatwg.org/wiki/RelExtensions


Finally, what was the upshoot of this email about the “magic” in fn?
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024881.html

Thanks for your time

peace - oli
@boblet

___
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