From tantek at cs.stanford.edu Mon Sep 1 17:02:22 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Mon Sep 1 17:02:53 2008 Subject: [uf-discuss] SXSWi2009 panel voting - consider microformats panel asap! Message-ID: <951346495-1220313765-cardhu_decombobulator_blackberry.rim.net-2082960706-@bxe118.bisx.prod.on.blackberry> Voting on panel proposals for SXSW Interactive 2009 ends in mere hours - if you haven't seen it yet, please consider voting for and commenting on the "State of the Microformats" panel: http://panelpicker.sxsw.com/ideas/view/1712 Please note in comments who you would want to see on the panel (including moderator), what you think the biggest advances in/with microformats have been (or will be in the near future), and whether you plan to attend SXSW2009. Thanks! Tantek From mail at tobyinkster.co.uk Tue Sep 2 08:40:50 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Tue Sep 2 08:41:27 2008 Subject: [uf-discuss] NetNewsWire ditches support for microformats Message-ID: Next downloadable version of Cognition ("downloadable" as against the web service) will include four plugins for NNW which do the following: hCard --> Address Book hCalendar --> iCal hAudio --> iTunes (all) --> RDF/XML in default text editor This uses NNW's scripting facility, so it sadly can't include any GUI icons to indicate the presence of any such data in the feed. (A custom NNW stylesheet could be used to indicate the presence of microformats though. Anyone want to design one?) -- Toby A Inkster From bhawkeslewis at googlemail.com Tue Sep 2 08:43:33 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Tue Sep 2 08:43:41 2008 Subject: [uf-discuss] datetime-design-pattern and the hAtom spec Message-ID: <48BD5F25.5020900@googlemail.com> Can the references in the hAtom draft: http://microformats.org/wiki/hatom to datetime-design-pattern (for published and updated) be safely modified to point instead to: http://microformats.org/wiki/machine-data#Embedding_Fixed_Data_Formats_in_Microformats -- Benjamin Hawkes-Lewis From karstenj at windows.microsoft.com Tue Sep 2 17:23:22 2008 From: karstenj at windows.microsoft.com (Karsten Januszewski) Date: Tue Sep 2 17:23:26 2008 Subject: [uf-discuss] URL and Relative paths Message-ID: <406D6FEFCBB98643A34170C59E1ABEF30F736233C4@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Hi - I'm a developer at Microsoft working on a project that involves parsing and consuming Microformats. I've noticed quite a few implementations of hCards out in the wild that use the url property with a relative path instead of an absolute path. Is this considered bad form? Or is this "to spec"? I didn't see anything on the wiki about this... Thanks, Karsten Januszewski From martin at weborganics.co.uk Tue Sep 2 17:45:28 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Tue Sep 2 17:45:40 2008 Subject: [uf-discuss] URL and Relative paths In-Reply-To: <406D6FEFCBB98643A34170C59E1ABEF30F736233C4@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <406D6FEFCBB98643A34170C59E1ABEF30F736233C4@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <48BDDE28.7010208@weborganics.co.uk> Hello Karsten Welcome! Karsten Januszewski wrote: > Hi - I'm a developer at Microsoft working on a project that involves parsing and consuming Microformats. I've noticed quite a few implementations of hCards out in the wild that use the url property with a relative path instead of an absolute path. > > Is this considered bad form? Or is this "to spec"? I didn't see anything on the wiki about this... > I think relative urls on the whole are "bad form" because many authors forget to set the base url for their relative paths... [....] I would say however that relative urls are useful in determining a sites internal links. I don't think the community on a whole has an opinion on that, but you may find a few individuals that do. Best Wishes Martin McEvoy > Thanks, > Karsten Januszewski > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From lists at ben-ward.co.uk Tue Sep 2 17:50:17 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Tue Sep 2 17:50:21 2008 Subject: [uf-discuss] URL and Relative paths In-Reply-To: <406D6FEFCBB98643A34170C59E1ABEF30F736233C4@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <406D6FEFCBB98643A34170C59E1ABEF30F736233C4@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <53FF3152-6D4E-493E-876C-29D214C1873D@ben-ward.co.uk> Hi Karsten, On 2 Sep 2008, at 17:23, Karsten Januszewski wrote: > Hi - I'm a developer at Microsoft working on a project that involves > parsing and consuming Microformats. I've noticed quite a few > implementations of hCards out in the wild that use the url property > with a relative path instead of an absolute path. This is completely valid. Publishers mark-up URLs just as they would for any hyperlink in their page. Anything that's valid in the href attribute is valid in hCard. It's very much the role of the parser to handle URLs in all their applicable forms. > I didn't see anything on the wiki about this... There won't be anything specific on the wiki because there are no restrictions over the existing usage in HTML. Good luck! Ben From mail at tobyinkster.co.uk Wed Sep 3 00:50:57 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Sep 3 00:51:30 2008 Subject: [uf-discuss] URL and Relative paths Message-ID: <8B49B41B-10BF-4751-8F2A-6509A3910C08@tobyinkster.co.uk> Karsten Januszewski wrote: > Is this considered bad form? Or is this "to spec"? I didn't see > anything on the wiki about this... "That which is not forbidden is mandatory." (Attributed to Murray Gell-Mann.) There's a whole bunch of weird code out there that people expect to be parsed. If it's not forbidden by the spec, then you've just got to roll up your sleeves and parse it. -- Toby A Inkster From martin at weborganics.co.uk Wed Sep 3 02:27:46 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Sep 3 02:27:56 2008 Subject: [uf-discuss] Ubiquity In-Reply-To: <107cffa30808271221w320420edu6f5ed5d0b39911b6@mail.gmail.com> References: <48B59D7D.4080907@weborganics.co.uk> <107cffa30808271221w320420edu6f5ed5d0b39911b6@mail.gmail.com> Message-ID: <48BE5892.40107@weborganics.co.uk> Hello Matthias, I nearly missed your email there so sorry for the late reply ;-) Gutjahr wrote: > Hey Martin, > > I tried it out, seems to work pretty well. Even recognizes the hAudio > in my blog (although transformr adds an ugly element .. > why?). Yes the iTunes extensions are because the RSS2 podcast extraction is mainly an iTunes podcast, If you have any better ideas on how to do this, you are welcome to comment. Take a look at http://weborganics.co.uk/haudio-rss/ for a few Ideas on how to get a better transformation from your source. > IMHO ubiquity is a cool tool, Very Cool.. > at least for us geeks ;O), and > you've come up with some good commands pretty quickly. > Thank You. > Cheers > - Matthias > Best wishes Martin McEvoy > 2008/8/27 Martin McEvoy : > >> Hey All >> >> Have you seen this >> >> http://labs.mozilla.com/2008/08/introducing-ubiquity/ >> >> Very Cool If you have tryed it out surf your way to >> http://transformr.co.uk/ for some Microformat commands they are, >> >> get-atom => get an atom feed from hatom >> get-vcard => from hcard >> get-events => get hCalendar Events >> get-podcast => Get a RSS2 podcast from hAudio >> get-rdfa => Gets RDF from RDFa documents >> >> >> Thanks >> >> Martin McEvoy >> _______________________________________________ >> 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 > From loertsch.thomas at guj.de Wed Sep 3 03:41:37 2008 From: loertsch.thomas at guj.de (Thomas Loertsch) Date: Wed Sep 3 03:41:46 2008 Subject: [uf-discuss] hRecipe implementation Message-ID: Hi there, I'm working at "essen & trinken" [1], a fairly popular website [2] about cooking in german. One of the main features of the site is a collection of about 10.000 recipes, all actually tried, categorized, etc. They are published as HTML 4 pages. We would like to make that collection more reusable. Adding some semantics to the presentational markup looks like a natural next step. While searching for a standard ontology we came across the hRecipe proposal, which by and large fits well with what we have already. We have some categories about nutritional values that are not covered by the current proposal [3]. If there?s a consensus that they fall outside the 80/20 rule - and I suppose there is - what would be the right way to handle them? Should we just add our own "microformat" for nutritional values? (We also have more detail in the yield field which I'm quite sure belong to /20). Another question about the status of the format: Some postings from August 2008 [4] suggest that people are already implementing it (or derivations of it) although I couldn?t find them on the web. Ted, is the prototype for Yahoo Food that you mentioned, available online? I'd be very interested in having a look at it! Then, last question: is there a timeframe until when a formal consensus on hRecipe will/should be reached? Will there ever be something like a "formal" consensus, an agreed upon recommendation? Or, in other words: is it reasonable to wait for a final version or is it more sensible and also 'okay' to go with what has already been achieved (since the current proposal on [3] already looks quite mature). Regards, Thomas [1] rough translation: "eating & drinking" [2] http://www.essen-und-trinken.de/ [3] http://microformats.org/wiki/recipe-brainstorming [4] http://microformats.org/discuss/mail/microformats-discuss/2008-August/012392 .html . Thomas L?rtsch Living at Home Multi Media GmbH Redaktion Online .. Stubbenhuk 5 20459 Hamburg Germany ... eMail: loertsch.thomas@guj.de From scott at randomchaos.com Wed Sep 3 06:14:24 2008 From: scott at randomchaos.com (Scott Reynen) Date: Wed Sep 3 06:33:47 2008 Subject: [uf-discuss] URL and Relative paths In-Reply-To: <48BDDE28.7010208@weborganics.co.uk> References: <406D6FEFCBB98643A34170C59E1ABEF30F736233C4@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48BDDE28.7010208@weborganics.co.uk> Message-ID: <9D819654-BDA7-4B8B-AEE5-EE3CEB7690C3@randomchaos.com> On [Sep 2], at [ Sep 2] 6:45 , Martin McEvoy wrote: > I think relative urls on the whole are "bad form" because many > authors forget to set the base url for their relative paths... There's nothing wrong with that. See: http://www.faqs.org/rfcs/rfc1808.html > 3.3. Base URL from the Retrieval URL > > If no base URL is embedded and the document is not encapsulated > within some other entity (e.g., the top level of a composite > entity), then, if a URL was used to retrieve the base document, that > URL shall be considered the base URL. Peace, Scott From csarven at gmail.com Wed Sep 3 07:09:47 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Wed Sep 3 07:09:52 2008 Subject: [uf-discuss] URL and Relative paths In-Reply-To: <9D819654-BDA7-4B8B-AEE5-EE3CEB7690C3@randomchaos.com> References: <406D6FEFCBB98643A34170C59E1ABEF30F736233C4@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48BDDE28.7010208@weborganics.co.uk> <9D819654-BDA7-4B8B-AEE5-EE3CEB7690C3@randomchaos.com> Message-ID: On Wed, Sep 3, 2008 at 9:14 AM, Scott Reynen wrote: > On [Sep 2], at [ Sep 2] 6:45 , Martin McEvoy wrote: > >> I think relative urls on the whole are "bad form" because many authors >> forget to set the base url for their relative paths... > > > There's nothing wrong with that. See: > > http://www.faqs.org/rfcs/rfc1808.html > >> 3.3. Base URL from the Retrieval URL >> >> If no base URL is embedded and the document is not encapsulated within >> some other entity (e.g., the top level of a composite entity), then, if a >> URL was used to retrieve the base document, that URL shall be considered the >> base URL. I was going to respond to this last night with an RFC line as well but figured that it wasn't a direct response to Martin's "bad form" statement. If I understand Martin's statement correctly (Martin, correct me if I'm wrong), he is talking about the general use of relative URLs in absence of the base element e.g., relative URLs from an external resource in an iframe can potentially resolve to unintended URIs if the base element is missing. Surely, a relative URL is resolved to full URI and in and of itself this is not "bad form". Sarven Capadisli http://www.csarven.ca From karstenj at windows.microsoft.com Wed Sep 3 11:14:49 2008 From: karstenj at windows.microsoft.com (Karsten Januszewski) Date: Wed Sep 3 11:17:51 2008 Subject: [uf-discuss] URL and Relative paths In-Reply-To: <8B49B41B-10BF-4751-8F2A-6509A3910C08@tobyinkster.co.uk> References: <8B49B41B-10BF-4751-8F2A-6509A3910C08@tobyinkster.co.uk> Message-ID: <406D6FEFCBB98643A34170C59E1ABEF30F73767C55@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Thanks for everyone's response - all very useful. It does appear that there is "a lot of weird code out there" and parsers have to try to account for it as best they can, depending on their purpose. Per the RFC, it is reasonable to do some string manipulation to create an absolute URL from a relative URL. And thanks for the welcome. You'll be hearing back from me as I continue to delve into Microformats. Regards, Karsten -----Original Message----- From: microformats-discuss-bounces@microformats.org [mailto:microformats-discuss-bounces@microformats.org] On Behalf Of Toby A Inkster Sent: Wednesday, September 03, 2008 12:51 AM To: microformats-discuss@microformats.org Subject: [uf-discuss] URL and Relative paths Karsten Januszewski wrote: > Is this considered bad form? Or is this "to spec"? I didn't see > anything on the wiki about this... "That which is not forbidden is mandatory." (Attributed to Murray Gell-Mann.) There's a whole bunch of weird code out there that people expect to be parsed. If it's not forbidden by the spec, then you've just got to roll up your sleeves and parse it. -- Toby A Inkster _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From tantek at cs.stanford.edu Wed Sep 3 11:22:38 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Wed Sep 3 11:23:42 2008 Subject: [uf-discuss] URL and Relative paths In-Reply-To: <406D6FEFCBB98643A34170C59E1ABEF30F73767C55@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <8B49B41B-10BF-4751-8F2A-6509A3910C08@tobyinkster.co.uk><406D6FEFCBB98643A34170C59E1ABEF30F73767C55@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <1868673043-1220466214-cardhu_decombobulator_blackberry.rim.net-670947169-@bxe118.bisx.prod.on.blackberry> Hi Karsten and welcome! URL processing is described in hcard-parsing on the wiki which can be used for much/moist microformat parsing: http://microformats.org/wiki/hcard-parsing#properties_of_type_URL_or_URI In general, handle relative URLs per the language of the document. For HTML follow the HTML spec (e.g. BASE handling etc.) There is nothing bad/wrong/inappropriate/weird about relative URLs as long as the document language allows them. Thanks, Tantek -----Original Message----- From: Karsten Januszewski Date: Wed, 3 Sep 2008 11:14:49 To: Microformats Discuss Subject: RE: [uf-discuss] URL and Relative paths Thanks for everyone's response - all very useful. It does appear that there is "a lot of weird code out there" and parsers have to try to account for it as best they can, depending on their purpose. Per the RFC, it is reasonable to do some string manipulation to create an absolute URL from a relative URL. And thanks for the welcome. You'll be hearing back from me as I continue to delve into Microformats. Regards, Karsten -----Original Message----- From: microformats-discuss-bounces@microformats.org [mailto:microformats-discuss-bounces@microformats.org] On Behalf Of Toby A Inkster Sent: Wednesday, September 03, 2008 12:51 AM To: microformats-discuss@microformats.org Subject: [uf-discuss] URL and Relative paths Karsten Januszewski wrote: > Is this considered bad form? Or is this "to spec"? I didn't see > anything on the wiki about this... "That which is not forbidden is mandatory." (Attributed to Murray Gell-Mann.) There's a whole bunch of weird code out there that people expect to be parsed. If it's not forbidden by the spec, then you've just got to roll up your sleeves and parse it. -- Toby A Inkster _______________________________________________ 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 From martin at weborganics.co.uk Wed Sep 3 11:50:37 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Sep 3 11:50:50 2008 Subject: [uf-discuss] URL and Relative paths In-Reply-To: References: <406D6FEFCBB98643A34170C59E1ABEF30F736233C4@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <48BDDE28.7010208@weborganics.co.uk> <9D819654-BDA7-4B8B-AEE5-EE3CEB7690C3@randomchaos.com> Message-ID: <48BEDC7D.3060000@weborganics.co.uk> Hello Sarven Sarven Capadisli wrote: > On Wed, Sep 3, 2008 at 9:14 AM, Scott Reynen wrote: > >> On [Sep 2], at [ Sep 2] 6:45 , Martin McEvoy wrote: >> >> >>> I think relative urls on the whole are "bad form" because many authors >>> forget to set the base url for their relative paths... >>> >> There's nothing wrong with that. See: >> >> http://www.faqs.org/rfcs/rfc1808.html >> >> >>> 3.3. Base URL from the Retrieval URL >>> >>> If no base URL is embedded and the document is not encapsulated within >>> some other entity (e.g., the top level of a composite entity), then, if a >>> URL was used to retrieve the base document, that URL shall be considered the >>> base URL. >>> > > > I was going to respond to this last night with an RFC line as well but > figured that it wasn't a direct response to Martin's "bad form" > statement. If I understand Martin's statement correctly (Martin, > correct me if I'm wrong), he is talking about the general use of > relative URLs in absence of the base element e.g., relative URLs from > an external resource in an iframe can potentially resolve to > unintended URIs if the base element is missing. > Yes Correct, Its bad in other ways because it makes parsers much more complex trying to determine things like: ./ .. ../ ../there ../.. ../../ ../../that Its just my opinion however so don't take me too seriously :-) > Surely, a relative URL is resolved to full URI and in and of itself > this is not "bad form". > No it isn't. Best Wishes Martin McEvoy > Sarven Capadisli > http://www.csarven.ca > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From karstenj at windows.microsoft.com Wed Sep 3 11:52:45 2008 From: karstenj at windows.microsoft.com (Karsten Januszewski) Date: Wed Sep 3 12:06:49 2008 Subject: [uf-discuss] URL and Relative paths In-Reply-To: <1868673043-1220466214-cardhu_decombobulator_blackberry.rim.net-670947169-@bxe118.bisx.prod.on.blackberry> References: <8B49B41B-10BF-4751-8F2A-6509A3910C08@tobyinkster.co.uk><406D6FEFCBB98643A34170C59E1ABEF30F73767C55@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <1868673043-1220466214-cardhu_decombobulator_blackberry.rim.net-670947169-@bxe118.bisx.prod.on.blackberry> Message-ID: <406D6FEFCBB98643A34170C59E1ABEF30F73767CC3@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Ah - That's just the info I was looking for; thanks for the link. I now get that relative URLs aren't necessarily "bad form" and it is the parsers responsibility to normalize them. Regards, Karsten -----Original Message----- From: microformats-discuss-bounces@microformats.org [mailto:microformats-discuss-bounces@microformats.org] On Behalf Of Tantek Celik Sent: Wednesday, September 03, 2008 11:23 AM To: ufdiscuss Subject: Re: [uf-discuss] URL and Relative paths Hi Karsten and welcome! URL processing is described in hcard-parsing on the wiki which can be used for much/moist microformat parsing: http://microformats.org/wiki/hcard-parsing#properties_of_type_URL_or_URI In general, handle relative URLs per the language of the document. For HTML follow the HTML spec (e.g. BASE handling etc.) There is nothing bad/wrong/inappropriate/weird about relative URLs as long as the document language allows them. Thanks, Tantek -----Original Message----- From: Karsten Januszewski Date: Wed, 3 Sep 2008 11:14:49 To: Microformats Discuss Subject: RE: [uf-discuss] URL and Relative paths Thanks for everyone's response - all very useful. It does appear that there is "a lot of weird code out there" and parsers have to try to account for it as best they can, depending on their purpose. Per the RFC, it is reasonable to do some string manipulation to create an absolute URL from a relative URL. And thanks for the welcome. You'll be hearing back from me as I continue to delve into Microformats. Regards, Karsten -----Original Message----- From: microformats-discuss-bounces@microformats.org [mailto:microformats-discuss-bounces@microformats.org] On Behalf Of Toby A Inkster Sent: Wednesday, September 03, 2008 12:51 AM To: microformats-discuss@microformats.org Subject: [uf-discuss] URL and Relative paths Karsten Januszewski wrote: > Is this considered bad form? Or is this "to spec"? I didn't see > anything on the wiki about this... "That which is not forbidden is mandatory." (Attributed to Murray Gell-Mann.) There's a whole bunch of weird code out there that people expect to be parsed. If it's not forbidden by the spec, then you've just got to roll up your sleeves and parse it. -- Toby A Inkster _______________________________________________ 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 _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From mail at tobyinkster.co.uk Wed Sep 3 12:55:45 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Sep 3 12:56:19 2008 Subject: [uf-discuss] URL and Relative paths Message-ID: <2A37D432-D7E3-400A-89C6-D3E26626CB69@tobyinkster.co.uk> Martin McEvoy wrote: > Yes Correct, Its bad in other ways because it makes parsers much more > complex Don't most programming languages have functions like relative URI resolution as built-ins or standard libraries? Perl certainly does - supporting relative URIs costs Cognition about two lines of code. Karsten: surely Microsoft must have at least one relative URI resolution function knocking around somewhere. -- Toby A Inkster From martin at weborganics.co.uk Wed Sep 3 16:18:06 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Sep 3 16:18:17 2008 Subject: [uf-discuss] [FYI] Ubiquity Command Message-ID: <48BF1B2E.6070403@weborganics.co.uk> Hello All There is now a Ubiquity[1] Command to search the microformats wiki with your words the command is: micro-search (your words) you can subscribe to it at http://weborganics.co.uk/ [https://wiki.mozilla.org/Labs/Ubiquity] Best Wishes Martin McEvoy From andreluis.pt at gmail.com Thu Sep 4 03:50:33 2008 From: andreluis.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Thu Sep 4 03:50:36 2008 Subject: [uf-discuss] [FYI] Ubiquity Command In-Reply-To: <48BF1B2E.6070403@weborganics.co.uk> References: <48BF1B2E.6070403@weborganics.co.uk> Message-ID: Whoa.. very handy Martin. Thank you very much. I think I would have prefered uf-search or uf-wiki since it's not only quicker to type but also more "memorable", at least for us folks. :) -- Andr? Lu?s On Thu, Sep 4, 2008 at 12:18 AM, Martin McEvoy wrote: > Hello All > > There is now a Ubiquity[1] Command to search the microformats wiki with your > words the command is: > > micro-search (your words) > > you can subscribe to it at http://weborganics.co.uk/ > > [https://wiki.mozilla.org/Labs/Ubiquity] > > Best Wishes > > Martin McEvoy > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From martin at weborganics.co.uk Thu Sep 4 04:04:41 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Sep 4 04:04:52 2008 Subject: [uf-discuss] [FYI] Ubiquity Command In-Reply-To: References: <48BF1B2E.6070403@weborganics.co.uk> Message-ID: <48BFC0C9.70009@weborganics.co.uk> Andr? Lu?s wrote: > Whoa.. very handy Martin. Thank you very much. > > I think I would have prefered uf-search or uf-wiki since it's not only > quicker to type but also more "memorable", at least for us folks. :) > Thanks Andr?, you are right changed to uf-search its much more memorable, if you have the command set to auto update just restart your browser and all should be well. Best Wishes Martin McEvoy > -- > Andr? Lu?s > > On Thu, Sep 4, 2008 at 12:18 AM, Martin McEvoy wrote: > >> Hello All >> >> There is now a Ubiquity[1] Command to search the microformats wiki with your >> words the command is: >> >> micro-search (your words) >> >> you can subscribe to it at http://weborganics.co.uk/ >> >> [https://wiki.mozilla.org/Labs/Ubiquity] >> >> Best Wishes >> >> Martin McEvoy >> _______________________________________________ >> 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 > From tantek at cs.stanford.edu Thu Sep 4 04:07:22 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Thu Sep 4 04:08:26 2008 Subject: [uf-discuss] [FYI] Ubiquity Command In-Reply-To: <48BFC0C9.70009@weborganics.co.uk> References: <48BF1B2E.6070403@weborganics.co.uk><48BFC0C9.70009@weborganics.co.uk> Message-ID: <206808122-1220526499-cardhu_decombobulator_blackberry.rim.net-565661074-@bxe118.bisx.prod.on.blackberry> Martin, good work. I encourage you to start a ubiquity page on our wiki and link to your additional commands etc. http://microformats.org/wiki/ubiquity Thanks, Tantek -----Original Message----- From: Martin McEvoy Date: Thu, 04 Sep 2008 12:04:41 To: Microformats Discuss Subject: Re: [uf-discuss] [FYI] Ubiquity Command Andr? Lu?s wrote: > Whoa.. very handy Martin. Thank you very much. > > I think I would have prefered uf-search or uf-wiki since it's not only > quicker to type but also more "memorable", at least for us folks. :) > Thanks Andr?, you are right changed to uf-search its much more memorable, if you have the command set to auto update just restart your browser and all should be well. Best Wishes Martin McEvoy > -- > Andr? Lu?s > > On Thu, Sep 4, 2008 at 12:18 AM, Martin McEvoy wrote: > >> Hello All >> >> There is now a Ubiquity[1] Command to search the microformats wiki with your >> words the command is: >> >> micro-search (your words) >> >> you can subscribe to it at http://weborganics.co.uk/ >> >> [https://wiki.mozilla.org/Labs/Ubiquity] >> >> Best Wishes >> >> Martin McEvoy >>_______________________________________________ >> 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 > _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From martin at weborganics.co.uk Thu Sep 4 06:44:21 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Sep 4 06:44:34 2008 Subject: [uf-discuss] [FYI] Ubiquity Command In-Reply-To: <206808122-1220526499-cardhu_decombobulator_blackberry.rim.net-565661074-@bxe118.bisx.prod.on.blackberry> References: <48BF1B2E.6070403@weborganics.co.uk><48BFC0C9.70009@weborganics.co.uk> <206808122-1220526499-cardhu_decombobulator_blackberry.rim.net-565661074-@bxe118.bisx.prod.on.blackberry> Message-ID: <48BFE635.20603@weborganics.co.uk> Tantek Celik wrote: > Martin, good work. > > I encourage you to start a ubiquity page on our wiki and link to your additional commands etc. > > http://microformats.org/wiki/ubiquity > Done! see: http://microformats.org/wiki/ubiquity Best Wishes Martin McEvoy > Thanks, > > Tantek > > -----Original Message----- > From: Martin McEvoy > > Date: Thu, 04 Sep 2008 12:04:41 > To: Microformats Discuss > Subject: Re: [uf-discuss] [FYI] Ubiquity Command > > > Andr? Lu?s wrote: > >> Whoa.. very handy Martin. Thank you very much. >> >> I think I would have prefered uf-search or uf-wiki since it's not only >> quicker to type but also more "memorable", at least for us folks. :) >> >> > > Thanks Andr?, you are right changed to uf-search its much more > memorable, if you have the command set to auto update just restart your > browser and all should be well. > > Best Wishes > > Martin McEvoy > >> -- >> Andr? Lu?s >> >> On Thu, Sep 4, 2008 at 12:18 AM, Martin McEvoy wrote: >> >> >>> Hello All >>> >>> There is now a Ubiquity[1] Command to search the microformats wiki with your >>> words the command is: >>> >>> micro-search (your words) >>> >>> you can subscribe to it at http://weborganics.co.uk/ >>> >>> [https://wiki.mozilla.org/Labs/Ubiquity] >>> >>> Best Wishes >>> >>> Martin McEvoy >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > 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 > From msporny at digitalbazaar.com Thu Sep 4 12:01:57 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Sep 4 12:58:47 2008 Subject: [uf-discuss] Today, Tomorrow, and Someday Problems Message-ID: <48C030A5.8090906@digitalbazaar.com> Interesting blog post by Shane McCarron of XHTML2 fame. He has been involved in the standards community since 1985. His name is on just about every major HTML standard to come out of the W3C - if you use HTML 4.01, XHTML1.0, XHTML 1.1, or will use XHTML2 (to name a few), you're using specs that he had a direct hand in creating or maintaining. It's interesting to see his take on how the W3C and the Microformats community fits into the ecosystem of solving the problems of today, tomorrow and "someday". The post discusses Microformats and RDFa: http://halindrome.blogspot.com/2008/09/why-we-do-what-we-do.html -- manu From martin at weborganics.co.uk Thu Sep 4 17:47:54 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Sep 4 17:48:14 2008 Subject: [uf-discuss] Today, Tomorrow, and Someday Problems In-Reply-To: <48C030A5.8090906@digitalbazaar.com> References: <48C030A5.8090906@digitalbazaar.com> Message-ID: <48C081BA.50908@weborganics.co.uk> Manu Sporny wrote: > Interesting blog post by Shane McCarron of XHTML2 fame. He has been > involved in the standards community since 1985. His name is on just > about every major HTML standard to come out of the W3C - if you use HTML > 4.01, XHTML1.0, XHTML 1.1, or will use XHTML2 (to name a few), you're > using specs that he had a direct hand in creating or maintaining. > > It's interesting to see his take on how the W3C and the Microformats > community fits into the ecosystem of solving the problems of today, > tomorrow and "someday". The post discusses Microformats and RDFa: > > http://halindrome.blogspot.com/2008/09/why-we-do-what-we-do.html > Thanks Manu for an interesting post, I have made some comments ;-) I am a bit worried about Shane's other post, http://halindrome.blogspot.com/2008/09/rdfa-is-proposed-recommendation.html > Unlike microformats, the idiom for annotating your content does not > conflict with the normal semantics of (X)HTML (e.g., the class > attribute, the title attribute, and abbr). Sound's like a declaration of war from a community who wants to bring Microformats to the fold. > Why would you want to use RDFa? For the same reason you want to use > microformats. Because you care about machines understanding what is on > your page, not just humans. Is it not the other way around in the microformats community? Best Wishes Martin McEvoy > -- manu > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From csarven at gmail.com Thu Sep 4 18:41:42 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Thu Sep 4 18:41:46 2008 Subject: [uf-discuss] Today, Tomorrow, and Someday Problems In-Reply-To: <48C081BA.50908@weborganics.co.uk> References: <48C030A5.8090906@digitalbazaar.com> <48C081BA.50908@weborganics.co.uk> Message-ID: On Thu, Sep 4, 2008 at 8:47 PM, Martin McEvoy wrote: >> Why would you want to use RDFa? For the same reason you want to use >> microformats. Because you care about machines understanding what is on your >> page, not just humans. > > Is it not the other way around in the microformats community? I don't think so. Both are essentially saying humans indeed do come first but we also want to help the machines understand a bit of what humans do. I think neither of them cancel out the need for the other. -Sarven From tantek at cs.stanford.edu Thu Sep 4 18:41:35 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Thu Sep 4 18:42:41 2008 Subject: [uf-discuss] Today, Tomorrow, and Someday Problems In-Reply-To: <48C081BA.50908@weborganics.co.uk> References: <48C030A5.8090906@digitalbazaar.com><48C081BA.50908@weborganics.co.uk> Message-ID: <300240328-1220578954-cardhu_decombobulator_blackberry.rim.net-1663141846-@bxe118.bisx.prod.on.blackberry> Martin, Manu, a brief bit of history. I left the W3C HTML WG and gave up on XHTML2 because I realized it was not "tomorrow" work, but rather "someday" work, or maybe even "never" work, became increasingly frustrated that the HTML WG as a whole ignored their necessary "today/tomorrow" work [1], and eventually decided that it was time that someone started to experiment with the broad semantic HTML *today* work being done by modern web designers, solving today's real world web problems, with shared vocabularies based on existing standards. I met up with Kevin Marks who had similar ideas and microformats was started. That was years ago (2003-2004). In the meantime, microformats adoption has taken off much faster than any of us could have hoped for, while XHTML2 is largely ignored. XHTML2 wasn't a "tomorrow" technology 5 years ago [1], and it still isn't today. You could say there may be some bitterness/resentment/jealousy/denial about that. Anyway, I'm largely ignoring it, as I'm trying to do my best to ignore the "microformats vs RDFa" baiting / artificial-dichotomy that so many have pursued. We have too much productive work to do to be distracted by such drama. Thanks, Tantek [1] http://tantek.com/log/2003/01.html#L20030114 -----Original Message----- From: Martin McEvoy Date: Fri, 05 Sep 2008 01:47:54 To: Microformats Discuss Subject: Re: [uf-discuss] Today, Tomorrow, and Someday Problems Manu Sporny wrote: > Interesting blog post by Shane McCarron of XHTML2 fame. He has been > involved in the standards community since 1985. His name is on just > about every major HTML standard to come out of the W3C - if you use HTML > 4.01, XHTML1.0, XHTML 1.1, or will use XHTML2 (to name a few), you're > using specs that he had a direct hand in creating or maintaining. > > It's interesting to see his take on how the W3C and the Microformats > community fits into the ecosystem of solving the problems of today, > tomorrow and "someday". The post discusses Microformats and RDFa: > > http://halindrome.blogspot.com/2008/09/why-we-do-what-we-do.html > Thanks Manu for an interesting post, I have made some comments ;-) I am a bit worried about Shane's other post, http://halindrome.blogspot.com/2008/09/rdfa-is-proposed-recommendation.html > Unlike microformats, the idiom for annotating your content does not > conflict with the normal semantics of (X)HTML (e.g., the class > attribute, the title attribute, and abbr). Sound's like a declaration of war from a community who wants to bring Microformats to the fold. > Why would you want to use RDFa? For the same reason you want to use > microformats. Because you care about machines understanding what is on > your page, not just humans. Is it not the other way around in the microformats community? Best Wishes Martin McEvoy > -- manu > > _______________________________________________ > 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 From msporny at digitalbazaar.com Thu Sep 4 23:38:22 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu Sep 4 23:38:28 2008 Subject: [uf-discuss] Today, Tomorrow, and Someday Problems In-Reply-To: <48C081BA.50908@weborganics.co.uk> References: <48C030A5.8090906@digitalbazaar.com> <48C081BA.50908@weborganics.co.uk> Message-ID: <48C0D3DE.4070201@digitalbazaar.com> Martin McEvoy wrote: >> http://halindrome.blogspot.com/2008/09/why-we-do-what-we-do.html >> > Thanks Manu for an interesting post, I have made some comments ;-) > I am a bit worried about Shane's other post > >> Shane wrote: >> Unlike microformats, the idiom for annotating your content does not >> conflict with the normal semantics of (X)HTML (e.g., the class >> attribute, the title attribute, and abbr). > > Sound's like a declaration of war from a community who wants to bring > Microformats to the fold. I've been working with Shane to get this "Microformats expression using RDFa" mechanism operational. I can assure you that his statements are absolutely not any sort of "declaration of war". Please refrain from using loaded language - it mis-characterizes and over-dramatizes his post. We're not talking about a terrible conflict involving loss of life. We're talking about a difference in opinion regarding web semantics expression - it's really geeky stuff. :) Shane has spent the most amount of time out of all of us in the RDFa and Microformats communities writing up our thoughts on Microformats expression using RDFa: http://rdfa.info/wiki/RDFa_Vocabularies He wouldn't be doing that if he wanted to harm this community in any way. We're trying to bring the two communities together - not push them apart. >> Why would you want to use RDFa? For the same reason you want to use >> microformats. Because you care about machines understanding what is on >> your page, not just humans. > > Is it not the other way around in the microformats community? As Sarven stated, the RDFa community and the Microformats community goals are the same - to enable widespread use of semantics in web documents. While the paths that both communities have taken are different, the destination is the same. -- manu From msporny at digitalbazaar.com Fri Sep 5 00:30:53 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Fri Sep 5 00:30:59 2008 Subject: [uf-discuss] Today, Tomorrow, and Someday Problems In-Reply-To: <300240328-1220578954-cardhu_decombobulator_blackberry.rim.net-1663141846-@bxe118.bisx.prod.on.blackberry> References: <48C030A5.8090906@digitalbazaar.com><48C081BA.50908@weborganics.co.uk> <300240328-1220578954-cardhu_decombobulator_blackberry.rim.net-1663141846-@bxe118.bisx.prod.on.blackberry> Message-ID: <48C0E02D.8050905@digitalbazaar.com> Tantek Celik wrote: > eventually decided that it was time that someone started to experiment > with the broad semantic HTML *today* work being done by modern web > designers, solving today's real world web problems, with shared > vocabularies based on existing standards. I met up with Kevin Marks > who had similar ideas and microformats was started. That being said, I owe a great debt to this community and the people that started it and continue to contribute, including you and the other uF founders, because it is here that I first saw that the semantic web was achievable in the near term. With over a 1,900 directly involved in this community, it is clear that the idea behind Microformats is something that resonates with us! The issue I had was with the execution of Microformats - most notably, the process and the parsing rules. It was only after hAudio ground to a halt (the second time) due to the many arguments revolving around the decision to not use "TITLE", pseudo-namespacing, scoping, accessibility, etc., that I followed up with the W3C as I became increasingly frustrated with the process. Our start-up had a problem to solve (mark-up of audio on web pages) and we wanted to do it right, through a standards body of some kind, instead of forcing our view on the world. We were determined to start an initiative to make the W3C take semantics in HTML more seriously. To our surprise, we found the RDFa Task Force who were doing just that. > That was years ago (2003-2004). In the meantime, microformats > adoption has taken off much faster than any of us could have > hoped for, while XHTML2 is largely ignored. XHTML2 wasn't a > "tomorrow" technology 5 years ago [1], and it still isn't > today. > You could say there may be some > bitterness/resentment/jealousy/denial about that. I joined the W3C as someone who was bitter about many of the standards that had passed the process. The nastiest scar that we held was a system-wide implementation of SOAP as our messaging protocol only to find out that the entire protocol was horrifically over-engineered. "It came from the W3C, it must be good", we thought. Similarly, we had issues with HTML 4.01 and a variety of other W3C technologies throughout the late 1990s and early 2000s. I don't take a strong position on XHTML2 or HTML5 because I have learned enough to know that there are too many people that want too many things out of both technologies to say that either standard is "good" or "bad", or solving today/tomorrow/someday problems. Everybody has different priorities and depending on one technology to solve all of our problems is never the answer. It's going to be a mix (HTML5, XHTML2, Javascript, Microformats, RDFa, etc.) like it has always been on the web. > Anyway, I'm largely ignoring it, as I'm trying to do my best > to ignore the "microformats vs RDFa" baiting / > artificial-dichotomy that so many have pursued. We have > too much productive work to do to be distracted by such drama. Agreed. There is too much work to be done and that getting involved in the perceived drama is distracting. When I hear someone talk about the "drama" between XHTML2 and HTML5, or Microformats and RDFa, it is usually in the form of false perceptions that one community has about the other. This is interesting because it breaks down into two categories: - People that think there is drama due to false perceptions on the positions that the other community holds. "The RDFa community is waging war on the Microformats community - I read about it in a blog post", or "The Microformats community thinks RDFa is just a repeat of RDF/XML." - People that have been burned by one community or the other in the past, usually during a design argument, which clouds their desire to work with the community ever again. So rather than actual drama, we have perceived drama because the communities aren't talking. We are letting false perceptions or negative experiences that we have had in the past cloud our ability to work with each other. This isn't directed at you, Tantek, as I know you strive to make your reasoning and thinking as fair and logical as possible. It's directed more at the general community (both RDFa and Microformats). There are a number of very good thinkers in each community and it is a shame that they continue to be separated because of false perceptions and clouded judgement. -- manu From martin at weborganics.co.uk Fri Sep 5 07:54:44 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Sep 5 07:54:57 2008 Subject: [uf-discuss] Today, Tomorrow, and Someday Problems In-Reply-To: References: <48C030A5.8090906@digitalbazaar.com> <48C081BA.50908@weborganics.co.uk> Message-ID: <48C14834.9010906@weborganics.co.uk> Sarven Capadisli wrote: > On Thu, Sep 4, 2008 at 8:47 PM, Martin McEvoy wrote: > >>> Why would you want to use RDFa? For the same reason you want to use >>> microformats. Because you care about machines understanding what is on your >>> page, not just humans. >>> >> Is it not the other way around in the microformats community? >> > > I don't think so. Both are essentially saying humans indeed do come > first but we also want to help the machines understand a bit of what > humans do. I think neither of them cancel out the need for the other. > OK you are right ...erm no you are wrong!...oh! I would write the same statement (with my microformats hat on): "... Because you care about Humans understanding what is on your page, not just machines." Best Wishes Martin McEvoy > -Sarven > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From karstenj at windows.microsoft.com Fri Sep 5 14:20:55 2008 From: karstenj at windows.microsoft.com (Karsten Januszewski) Date: Fri Sep 5 14:21:02 2008 Subject: [uf-discuss] ignoring minimal hCards Message-ID: <406D6FEFCBB98643A34170C59E1ABEF30F73FA0B8F@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Hello - I'm finding lots of great sites out there that are using Microformats, hCards and hCalendars, in particular, to maximum effect where there is real value in the data they mark up. (Eventful.com and upcoming.yahoo.com come to mind.) However, I'm seeing other sites where a minimal amount of information is provided (fn, photo, url to page relative to the site). This data may be of interest from a search index perspective. However, for an application consuming Microformats, it is of less interest. Consider Twitter: my Twitter profile page has 120 hCards on it (representing everyone who is following me on Twitter), but none of those hCards contain any real interesting data. I understand this is a side effect of the fact that only FN is required in hCard. What are people's thoughts on sites that minimally adopt Microformats? Right now, I'm working on both a parser and an application. What if my application were to ignore Microformats that may be to spec but weren't interesting enough for my application's purpose? Yes, a subjective decision, but I'm wondering what the community would think of such a decision. Thanks, Karsten From csarven at gmail.com Fri Sep 5 14:36:26 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Fri Sep 5 14:36:31 2008 Subject: [uf-discuss] ignoring minimal hCards In-Reply-To: <406D6FEFCBB98643A34170C59E1ABEF30F73FA0B8F@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <406D6FEFCBB98643A34170C59E1ABEF30F73FA0B8F@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: On Fri, Sep 5, 2008 at 5:20 PM, Karsten Januszewski wrote: > Consider Twitter: my Twitter profile page has 120 hCards on it (representing everyone who is following me on Twitter), but none of those hCards contain any real interesting data. > > I understand this is a side effect of the fact that only FN is required in hCard. What are people's thoughts on sites that minimally adopt Microformats? To some extent. If an hCard contains the url property (arguable one of the most valuable), further information can be obtained about that contact by following up on the resource. Sarven Capadisli http://www.csarven.ca From bhawkeslewis at googlemail.com Fri Sep 5 14:39:46 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Fri Sep 5 14:39:53 2008 Subject: [uf-discuss] ignoring minimal hCards In-Reply-To: <406D6FEFCBB98643A34170C59E1ABEF30F73FA0B8F@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <406D6FEFCBB98643A34170C59E1ABEF30F73FA0B8F@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <48C1A722.8020303@googlemail.com> Karsten Januszewski wrote: > What if my application were to ignore Microformats that may be to spec but weren't interesting enough for my application's purpose? As long as your application doesn't pretend to the user that it is extracting all hCards when it isn't, I can't see how anyone could object to this. :) -- Benjamin Hawkes-Lewis From mail at tobyinkster.co.uk Fri Sep 5 14:44:20 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri Sep 5 14:44:51 2008 Subject: [uf-discuss] ignoring minimal hCards Message-ID: Karsten Januszewski wrote: > Right now, I'm working on both a parser and an application. What if > my application were to ignore Microformats that may be to spec but > weren't interesting enough for my application's purpose? Yes, a > subjective decision, but I'm wondering what the community would > think of such a decision. That sounds fine to me. If you've got an application that is designed to, say, add people's portraits to a photo management tool, then ignoring hCards which don't have a "photo" property would seem to be a good move. If your app takes contact details from a web page to transfer to a phone via bluetooth, it is probably sensible to skip hCards that don't contain a phone number. Microformats are about marking up the information on the page - not compelling parsers to do anything in particular with it. -- Toby A Inkster From martin at weborganics.co.uk Fri Sep 5 15:39:17 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Fri Sep 5 15:39:25 2008 Subject: [uf-discuss] ignoring minimal hCards In-Reply-To: <406D6FEFCBB98643A34170C59E1ABEF30F73FA0B8F@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <406D6FEFCBB98643A34170C59E1ABEF30F73FA0B8F@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <48C1B515.5050509@weborganics.co.uk> Hello Karsten Karsten Januszewski wrote: > Hello - I'm finding lots of great sites out there that are using Microformats, hCards and hCalendars, in particular, to maximum effect where there is real value in the data they mark up. (Eventful.com and upcoming.yahoo.com come to mind.) However, I'm seeing other sites where a minimal amount of information is provided (fn, photo, url to page relative to the site). This data may be of interest from a search index perspective. However, for an application consuming Microformats, it is of less interest. > > Consider Twitter: my Twitter profile page has 120 hCards on it (representing everyone who is following me on Twitter), but none of those hCards contain any real interesting data. > I have noticed on many social networking sites such as Twitter, Magnolia, LastFM... etc use XFN to define which hcard's belong to who for example Twitter, Magnolia and LastFM use @rel=me to idenifiy the Users profile hcard and @rel=contact to mark up the hcards of a users er.. contacts., this pattern is found on a few blogs and homepages too. There is and Demo on how all this information can be put together, you may find it useful in your quest take a look at there is also a wiki page with lots more examples of hcard's supporting user profiles here: Best wishes Martin McEvoy > I understand this is a side effect of the fact that only FN is required in hCard. What are people's thoughts on sites that minimally adopt Microformats? > > Right now, I'm working on both a parser and an application. What if my application were to ignore Microformats that may be to spec but weren't interesting enough for my application's purpose? Yes, a subjective decision, but I'm wondering what the community would think of such a decision. > > Thanks, > Karsten > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From glenn.jones at madgex.com Mon Sep 8 03:44:46 2008 From: glenn.jones at madgex.com (Glenn Jones) Date: Mon Sep 8 03:44:56 2008 Subject: [uf-discuss] Microformats and OAuth Message-ID: <36A319113CF910438942741C4727ADFF0249982D@MOBY.Clarence.local> Hi All On Friday, Madgex has open-sourced a new c# OAuth library called OAuth.net. One of the demos is an example of using Microformats and OAuth together. We have built a very simple site which has a protected page containing an hCard. Using OAuth you can authorise access to the page at which point the demo site uses a microformats parser (ufXtract) to collect the contact details and pre-fill a form. Demo start ( go here and try it out ) http://lab.madgex.com/oauth-net/provider/ Page with hCard protect with OAuth http://oauthproviderdemo.madgex.com/user/contactdetails.aspx/ Username: testuser Password: letmein Currently, I am happy to publicly mark-up my work address in web pages, but not my home address. When I use XFN I never mark-up family members. However, by using this type of access control we could all mark-up more personal information. This demo was put together as a technical example, but with a little effort I am sure we could build a compelling user experience, which took the best elements of UF concept and added privacy. Glenn Jones From chris.messina at gmail.com Mon Sep 8 10:42:39 2008 From: chris.messina at gmail.com (Chris Messina) Date: Mon Sep 8 10:42:45 2008 Subject: [uf-discuss] Microformats and OAuth In-Reply-To: <36A319113CF910438942741C4727ADFF0249982D@MOBY.Clarence.local> References: <36A319113CF910438942741C4727ADFF0249982D@MOBY.Clarence.local> Message-ID: <1bc4603e0809081042y6a536af3j2279bd88d3eeebb2@mail.gmail.com> Hey Glenn This is awesome! It's something we're already supporting in DiSo, so it's nice to see the concept take off elsewhere. I have one issue with your demo... if I deny access, I'm returned to the consumer with the message: "You have a stored authentication to the contacts details API." And then the option to "remove granted access". See: http://flickr.com/photos/factoryjoe/2839663959/ The problem is that I never granted access in the first place, so I'm concerned that there's actually no security benefit to using OAuth in this situation...! Have you checked this out? Chris On Mon, Sep 8, 2008 at 3:44 AM, Glenn Jones wrote: > Hi All > > On Friday, Madgex has open-sourced a new c# OAuth library called > OAuth.net. > > One of the demos is an example of using Microformats and OAuth together. > We have built a very simple site which has a protected page containing > an hCard. Using OAuth you can authorise access to the page at which > point the demo site uses a microformats parser (ufXtract) to collect the > contact details and pre-fill a form. > > Demo start ( go here and try it out ) > http://lab.madgex.com/oauth-net/provider/ > > Page with hCard protect with OAuth > http://oauthproviderdemo.madgex.com/user/contactdetails.aspx/ > > Username: testuser > Password: letmein > > Currently, I am happy to publicly mark-up my work address in web pages, > but not my home address. When I use XFN I never mark-up family members. > However, by using this type of access control we could all mark-up more > personal information. This demo was put together as a technical example, > but with a little effort I am sure we could build a compelling user > experience, which took the best elements of UF concept and added > privacy. > > > > Glenn Jones > > > > > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- Chris Messina Citizen-Participant & Open Source Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [ ] bloggable [X] ask first [ ] private From chris.messina at gmail.com Mon Sep 8 10:44:34 2008 From: chris.messina at gmail.com (Chris Messina) Date: Mon Sep 8 10:44:40 2008 Subject: [uf-discuss] NetNewsWire ditches support for microformats In-Reply-To: References: Message-ID: <1bc4603e0809081044ra3ce40csf198eaa8b92bd2c6@mail.gmail.com> Awesome! I wrote a stylesheet for NetNewsWire (FactoryLegible). I have the X-Ray bookmarklet embedded, but think it'd be cool if there were contacts or events embedded in the page, I could pull them out and make them extractable. I'd love some help adding support for these plugins to my stylesheet -- anyone want to help? Also, with a bookmarklet, how do you generate an in-page downloadable VCF file? Chris On Tue, Sep 2, 2008 at 8:40 AM, Toby A Inkster wrote: > Next downloadable version of Cognition ("downloadable" as against the web > service) will include four plugins for NNW which do the following: > > hCard --> Address Book > hCalendar --> iCal > hAudio --> iTunes > (all) --> RDF/XML in default text editor > > This uses NNW's scripting facility, so it sadly can't include any GUI icons > to indicate the presence of any such data in the feed. (A custom NNW > stylesheet could be used to indicate the presence of microformats though. > Anyone want to design one?) > > -- > Toby A Inkster > > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- Chris Messina Citizen-Participant & Open Source Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [ ] bloggable [X] ask first [ ] private From chris.messina at gmail.com Mon Sep 8 10:59:42 2008 From: chris.messina at gmail.com (Chris Messina) Date: Mon Sep 8 10:59:47 2008 Subject: [uf-discuss] OpenCalais automates microformatting of content Message-ID: <1bc4603e0809081059i2cf2e601gc1b10d6c0247ae71@mail.gmail.com> I actually stumbled upon this from a Google AdSense link, but there's some interesting stuff going on at http://opencalais.com/. This project was mentioned back in February and at the time, was primarily dedicated to adding RDFa output to blog posts. Well, I guess they saw the light and now have an API that will add microformats to your blog posts, based on semantic analysis: http://opencalais.com/about It's being powered/sponsored by Reuters, so you can imagine why they're interested in this (basically being able to remine all the content they have in all their many news archives and databases). If you want to get into the good stuff, visit their tools page: http://opencalais.com/tools The most interesting projects are: Calais Marmoset - http://opencalais.com/Crawler Tagaroo - http://tagaroo.opencalais.com/ (Alex King's CrowdFavorite contributed to this project) Gnosis - http://opencalais.com/Gnosis Now, I haven't really played with the API, and I'm a little wary of their actual microformats output, but you can get a sense for what they're doing on this page: http://opencalais.com/Microformats If anything, I think there's some real promise to this approach and love the idea of being able to automatically microformat content as it's published to a blog or output from a CMS. Can anyone take a look at this and give us a sense for how good these tools are? Chris -- Chris Messina Citizen-Participant & Open Source Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [X] bloggable [ ] ask first [ ] private From guillaume at lebleu.org Mon Sep 8 11:31:06 2008 From: guillaume at lebleu.org (Guillaume P. Lebleu) Date: Mon Sep 8 11:31:10 2008 Subject: [uf-discuss] OpenCalais automates microformatting of content In-Reply-To: <1bc4603e0809081059i2cf2e601gc1b10d6c0247ae71@mail.gmail.com> References: <1bc4603e0809081059i2cf2e601gc1b10d6c0247ae71@mail.gmail.com> Message-ID: On Sep 8, 2008, at 10:59 AM, Chris Messina wrote: > > Can anyone take a look at this and give us a sense for how good > these tools are? > I reviewed the OpenCalais RDF extraction earlier this year with both non-financial and financial/PR content [1]. At the time, OpenCalais fared much much better with financial/PR content than with general content. [1] http://lebleu.org/blog/tags/opencalais/ From jim at eatyourgreens.org.uk Mon Sep 8 11:39:36 2008 From: jim at eatyourgreens.org.uk (Jim O'Donnell) Date: Mon Sep 8 11:39:45 2008 Subject: [uf-discuss] OpenCalais automates microformatting of content In-Reply-To: <1bc4603e0809081059i2cf2e601gc1b10d6c0247ae71@mail.gmail.com> References: <1bc4603e0809081059i2cf2e601gc1b10d6c0247ae71@mail.gmail.com> Message-ID: <282699D3-2706-4252-809B-ADCF838E1954@eatyourgreens.org.uk> I'm afraid I've got no direct experience of opencalais mself, but the Powerhouse Museum in Sydney have been using it to tag their catalogue records with people, places and so on. Seb Chan blogged about it in March: http://tinyurl.com/semantictagging I'm not sure if they carried on with this experiment, but the initial examples on Seb's blog seemed impressive. At this year's Mashed Museum in Leicester, Steve Pope from Eduserve also did some interesting stuff running text from online museum catalogues through opencalais, which gets a bit of a mention here: http://electronicmuseum.org.uk/2008/06/27/mashed-museum-2008/ Jim On 8 Sep 2008, at 18:59, Chris Messina wrote: > I actually stumbled upon this from a Google AdSense link, but there's > some interesting stuff going on at http://opencalais.com/. > > This project was mentioned back in February and at the time, was > primarily dedicated to adding RDFa output to blog posts. Well, I guess > they saw the light and now have an API that will add microformats to > your blog posts, based on semantic analysis: > > http://opencalais.com/about > > It's being powered/sponsored by Reuters, so you can imagine why > they're interested in this (basically being able to remine all the > content they have in all their many news archives and databases). > > If you want to get into the good stuff, visit their tools page: > > http://opencalais.com/tools > > The most interesting projects are: > > Calais Marmoset - http://opencalais.com/Crawler > Tagaroo - http://tagaroo.opencalais.com/ (Alex King's CrowdFavorite > contributed to this project) > Gnosis - http://opencalais.com/Gnosis > > Now, I haven't really played with the API, and I'm a little wary of > their actual microformats output, but you can get a sense for what > they're doing on this page: > > http://opencalais.com/Microformats > > If anything, I think there's some real promise to this approach and > love the idea of being able to automatically microformat content as > it's published to a blog or output from a CMS. > > Can anyone take a look at this and give us a sense for how good > these tools are? > > Chris > > -- > Chris Messina > Citizen-Participant & > Open Source Advocate-at-Large > factoryjoe.com # diso-project.org > citizenagency.com # vidoop.com > This email is: [X] bloggable [ ] ask first [ ] private Jim O'Donnell jim@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens From zack.carter at gmail.com Mon Sep 8 14:11:26 2008 From: zack.carter at gmail.com (Zachary Carter) Date: Mon Sep 8 14:11:29 2008 Subject: [uf-discuss] Employment end dates in hResume - outstanding issue In-Reply-To: References: Message-ID: +1 for this as something that should be resolved. A standard procedure for this would be needed for interoperability. I could see this being useful for hCalendar also, though the most common occurrence of events with indefinite end dates do happen to be within hResume. Another usecase could be a historical timeline marking the current age as the "Information Age," which would be ongoing. I like a solution (such as yours) where the parser can take the burden of including the current date if necessary, as the publisher might not be able to generate the current date dynamically. When the parser sees the 'ongoing' class it could insert the current date as dtend if appropriate when exported to a static format. Best, Zach Carter http://zachcarter.info On Fri, Aug 29, 2008 at 7:24 AM, Ciaran McNulty wrote: > As there's been some discussion about moving drafts into specification > status lately, I'd like to address one of the outstanding issues in > hResume. > > The problem that has arisen quite a few times, is that a lot of people > with a resume are currently employed and don't know what to provide as > the DTEND in their markup for their current job. The problem is not > as apparent with educational events, as they tend to have a defined > end point even if it's in the future (PhD students may argue, mind > you). > > The solutions in the wild tend to be either: > > 1. Set the DTEND to the date the resume was generated. > The problem with this approach is that if I save your resume and come > back and look at it in a year's time, I might think your employment > period ended on that date. > > 2. Set the DTEND to some far-future date. > This could be confusing and could be taken to indicate that your > contract ends at some specified date in the future. > > 3. Set the DTEND to the same as DTSTART. > This makes the event be either instantaneous or 1 day long in > hCalendar, which could be confusing. > > 4. Omit the DTEND. > This is actually equivalent to option 3 (see > http://microformats.org/discuss/mail/microformats-discuss/2006-October/006477.html) > > Personally I don't think this problem is going to be solvable within > hCalendar, and 'ongoing' events may be somewhat out of spec for that > particular format. I would lean towards choosing one of the above > approaches and defining some optional additional semantic within > hResume that indicates that an experience event is 'ongoing'. > > My particular preference would be to recommend option 4 and add a > @class="ongoing" that can be added to an event in hResume: > > >
> Managing Director > Example PLC > 2002 > to > 2005 >
> > >
> CEO > Another PLC > 2005 > to > Present >
> > When viewed by an hCalendar parser, the second event would be > considered to be an all-day event occuring on 23rd Jan 2005. An > hResume parser would however note the presence of @class="ongoing" > within the event and be able to > > I'd welcome any feedback about: > > A. Whether this is a problem that needs solving, or if there's an > obvious way of representing these events in hCalendar that we've all > missed. > B. Whether it needs to be solved by adding a concept of 'now' to > hCalendar or whether it needs to be solved in hResume as I've > suggested. > C. What people think of my example markup. > > Thanks, > > -Ciaran McNulty > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From mail at tobyinkster.co.uk Mon Sep 8 15:20:25 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Mon Sep 8 15:27:56 2008 Subject: [uf-discuss] NetNewsWire ditches support for microformats Message-ID: > Also, with a bookmarklet, how do you generate an in-page > downloadable VCF file? I don't - they're not bookmarklets, but AppleScripts, executed from NNW's script menu. The applescript calls the Cognition command-line client (which, yes, needs to be installed), which outputs a VCF to a temporary directory and then opens that VCF with iCalendar. Same principle for M3U in iTunes and ICS in iCal. -- Toby A Inkster From george.brocklehurst at gmail.com Wed Sep 10 05:30:54 2008 From: george.brocklehurst at gmail.com (George Brocklehurst) Date: Wed Sep 10 05:31:11 2008 Subject: [uf-discuss] Benefits of Microformats Message-ID: Hi all, After discovering some misinformation about Microformats on the new stackoverflow.com programmer Q&A site and a few conversations last night at the Microformats London dinner I felt there was a need to add a page to the wiki explaining the benefits of Microformats to publishers. We do a great job at telling people what ufs are and how to use them, but we're not so great at telling people why they should care. So, I give you http://microformats.org/wiki/benefits Please do add to, edit and generally improve on the things already listed. As an aside, if anyone's interested this is the accepted answer to "should I used Microformats?" on stackoverflow.com that got me thinking about the benefits page. Given that the stated aim of Stack Overflow is to become the canonical online guide to all things programming, I wanted to fix it: > I think almost anything you'd like to put into a microformat you > could make something with a "full" format. hCard.. you could just > make a simple vCard file. hCalendar? Make an icalendar file you > update and link to it. The advantage to NOT using microformats is > that you can use almost any application that supports calendar/ > contact etc information and point them at the "full" format instead > of the microformat, which requires consumer applications to add more > functionality. > > To me, that's just the state of things now. I have no technical > reason to not use them. I just think that if you just make the > "full" format, applications consuming this information are more > likely to support/handle it. Though the rel="me" stuff is extra > information that you don't get from other things. I'd say use those > since they're easy, and adds information that no other format/ > standard really does (that I know of). Thanks, G From brian.suda at gmail.com Wed Sep 10 06:09:46 2008 From: brian.suda at gmail.com (Brian Suda) Date: Wed Sep 10 06:09:50 2008 Subject: [uf-discuss] Benefits of Microformats In-Reply-To: References: Message-ID: <21e770780809100609m5834585as56baf70c79377151@mail.gmail.com> On Wed, Sep 10, 2008 at 12:30 PM, George Brocklehurst wrote: >> I think almost anything you'd like to put into a microformat you could >> make something with a "full" format. hCard.. you could just make a simple >> vCard file. hCalendar? Make an icalendar file you update and link to it. The >> advantage to NOT using microformats is that you can use almost any >> application that supports calendar/contact etc information and point them at >> the "full" format instead of the microformat, which requires consumer >> applications to add more functionality. >> >> To me, that's just the state of things now. I have no technical reason to >> not use them. I just think that if you just make the "full" format, >> applications consuming this information are more likely to support/handle --- i think that really needs to be updated. They are missing the point of semantic mark-up over flat files completely. Firstly, flat files are out-of-sight and therefore out-of-mind. The data drift is much more likely than files (HTML) you stare at on a daily basis. Their argument of the consumer application [needs] to add more functionality is moot. I have my hCard, but then the link people click to download the vCard just uses a webservice and returns the "full" format anyway. The consumer application needed nothing more than normal. One thing that i always try to remember is that one-off quote from the movie contact. They give Jodie Foster some pills so if she gets into trouble she can poison herself. They give her the pills "Not for all the reasons they can think of, but for all the reasons they can't" That idea is really exemplified in semantic mark-up for individual "full" formats. You COULD try to create 2334 different flat files on your server and offer each one, but those are for everything you CAN think of, semantic mark-up is great for all the formats you CAN?T think of! Empower the consumers to re-use the data as they want to, rather than how you tell them. We should really try to update benefits in this way. Good spot on stackoverflow.com can we change it somehow? Thanks, -brian -- brian suda http://suda.co.uk From george.brocklehurst at gmail.com Wed Sep 10 06:40:48 2008 From: george.brocklehurst at gmail.com (George Brocklehurst) Date: Wed Sep 10 06:41:01 2008 Subject: [uf-discuss] Benefits of Microformats In-Reply-To: <21e770780809100609m5834585as56baf70c79377151@mail.gmail.com> References: <21e770780809100609m5834585as56baf70c79377151@mail.gmail.com> Message-ID: Hi Brian, On 10 Sep 2008, at 14:09, Brian Suda wrote: > We should really try to update benefits in this way. Good spot on > stackoverflow.com can we change it somehow? The theory behind the stackoverflow is that good answers float to the top as different answers are voted on as helpful or unhelpful, so the best way to change it would be to go to the stack overflow site (once it's out of closed beta, which should be in the next week or so) and vote. Unless they make a lot of changes, the relevant URL should be: http://www.stackoverflow.com/questions/tagged/microformats I've also provided an alternative answer along the lines of what you've said about flat files vs. semantic markup. G From brian.suda at gmail.com Thu Sep 11 10:55:36 2008 From: brian.suda at gmail.com (Brian Suda) Date: Thu Sep 11 10:55:41 2008 Subject: [uf-discuss] Microformats stickers Message-ID: <21e770780809111055m6ac5855btdef94ce927edd566@mail.gmail.com> In the past people have asked about the microformats stickers. We only made a short run of the original large ones. So to help fill the demand, I have used the Moo API to generate microformats stickers that anyone can just click and order. http://suda.co.uk/projects/microformats/moo/ There are a variety of different colors, but you can un-check any that you do not want. Ideally, i tried to cover the common laptop colors along with some fun bright colors as well. I am open to suggestions for additions/deletions, etc. Let me know your thoughts, -brian -- brian suda http://suda.co.uk From hober0 at gmail.com Thu Sep 11 11:17:51 2008 From: hober0 at gmail.com (Edward O'Connor) Date: Thu Sep 11 11:17:54 2008 Subject: [uf-discuss] Microformats stickers In-Reply-To: <21e770780809111055m6ac5855btdef94ce927edd566@mail.gmail.com> References: <21e770780809111055m6ac5855btdef94ce927edd566@mail.gmail.com> Message-ID: <3b31caf90809111117w4e7c199fj4e7c72fb473de60d@mail.gmail.com> > So to help fill the > demand, I have used the Moo API to generate microformats stickers that > anyone can just click and order. [...] > Let me know your thoughts, These are great! I think I'll order a bunch to give out at our next local BarCamp. Thanks for making them! Ted From mdagn at spraci.com Thu Sep 11 17:22:13 2008 From: mdagn at spraci.com (MichaelMD) Date: Thu Sep 11 17:22:16 2008 Subject: [uf-discuss] Microformats stickers In-Reply-To: <21e770780809111055m6ac5855btdef94ce927edd566@mail.gmail.com> References: <21e770780809111055m6ac5855btdef94ce927edd566@mail.gmail.com> Message-ID: <1221178933.6141.18.camel@droid2> On Thu, 2008-09-11 at 17:55 +0000, Brian Suda wrote: > In the past people have asked about the microformats stickers. We only > made a short run of the original large ones. So to help fill the > demand, I have used the Moo API to generate microformats stickers that > anyone can just click and order. > > http://suda.co.uk/projects/microformats/moo/ nice idea... I'm thinking about ordering some to give to bloggers at Newcastle Fringe Festival. ..but given that some of them might be unfamiliar with microformats it might be good to have microformats.org on there somewhere so they can look up the info. also - how long would they take to ship them to Australia? (Newcastle Fringe is only a couple of weeks away) From Charles.Belov at sfmta.com Thu Sep 11 17:57:11 2008 From: Charles.Belov at sfmta.com (Belov, Charles) Date: Thu Sep 11 17:57:15 2008 Subject: [uf-discuss] RE: Data drift vs. ISO dates WAS Benefits of Microformats In-Reply-To: <200809120024.m8C0NwPU021534@microformats.org> References: <200809120024.m8C0NwPU021534@microformats.org> Message-ID: If you are sick of the ISO date disagreement, you may want to skip this message. > -----Original Message----- > Message: 4 > Date: Wed, 10 Sep 2008 13:09:46 +0000 > From: "Brian Suda" > Subject: Re: [uf-discuss] Benefits of Microformats > To: "Microformats Discuss" > Message-ID: > <21e770780809100609m5834585as56baf70c79377151@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Sep 10, 2008 at 12:30 PM, George Brocklehurst > wrote: >>> I think almost anything you'd like to put into a microformat you could >>> make something with a "full" format. hCard.. you could just make a simple >>> vCard file. hCalendar? Make an icalendar file you update and link to it. The >>> advantage to NOT using microformats is that you can use almost any >>> application that supports calendar/contact etc information and point them at >>> the "full" format instead of the microformat, which requires consumer >>> applications to add more functionality. >>> >>> To me, that's just the state of things now. I have no technical reason to >>> not use them. I just think that if you just make the "full" format, >>> applications consuming this information are more likely to support/handle > > --- i think that really needs to be updated. They are missing the > point of semantic mark-up over flat files completely. Firstly, flat > files are out-of-sight and therefore out-of-mind. The data drift is > much more likely than files (HTML) you stare at on a daily basis. So are abbr tags hiding ISO dates. I can see somebody changing the publicly visible date and forgetting to change the hidden ISO date. This of course is not an issue for programmatically generated pages, but it is certainly an issue for manually-edited ones. (This is also assuming the content entry person can reliably generate ISO dates and times in the first place.) Data drift is a very big argument against using hidden ISO dates, and human-friendliness is a very big argument against showing them. One more reason not to use ISO dates. Hope this helps, Charles "Chas" Belov SFMTA Webmaster From paul.m.wilkins at gmail.com Fri Sep 12 14:15:23 2008 From: paul.m.wilkins at gmail.com (Paul Wilkins) Date: Fri Sep 12 14:15:36 2008 Subject: [uf-discuss] RE: Data drift vs. ISO dates WAS Benefits of Microformats In-Reply-To: References: <200809120024.m8C0NwPU021534@microformats.org> Message-ID: On Fri, Sep 12, 2008 at 1:57 PM, Belov, Charles wrote: > Data drift is a very big argument against using hidden ISO dates, and > human-friendliness is a very big argument against showing them. One more > reason not to use ISO dates. Is it a valid conclusion then that placing a date marker around a text-based date is a suitable solution, leaving the parsing of valid data to a parser of some nature? -- Paul Wilkins From mdagn at spraci.com Fri Sep 12 20:25:51 2008 From: mdagn at spraci.com (MichaelMD) Date: Fri Sep 12 20:25:53 2008 Subject: [uf-discuss] RE: Data drift vs. ISO dates WAS Benefits of Microformats In-Reply-To: References: <200809120024.m8C0NwPU021534@microformats.org> Message-ID: <1221276351.6136.96.camel@droid2> > Is it a valid conclusion then that placing a date marker around a > text-based date is a suitable solution, leaving the parsing of valid > data to a parser of some nature? > no... People often write dates that are ambiguous even to other humans, let alone machines. Nobody is going to convince me that something like 12/09/08 could even be considered human readable let alone machine readable. Someone is Europe or Australia might see it as 12th September 2008 someone in USA might see it as December 9th, 2008 - and - using localisation cannot be considered reliable at the the server end of things. (the only place where it might be reliable in the real world is for a translated display in a client based on user preferences) I've often seen sites here in Australia showing dates the American way because that is the default settings in their CMS (and what about people posting on a site that isn't their own site? - perhaps even in a different country?). Humans are pretty good at guessing what date format is being used because they take into account a lot of other factors like the type of event, what date ranges such an event is more likely to be in,the type of page they are looking at and memories of similar pages they have seen before, and even then they can sometimes still get it wrong. I'm not afraid to show humans something like 2008-09-12. At least both people and machines usually get it right without needing to know something about its context. People who have never seen dates written like 2008-09-12 still usually work it out correctly (even if they think it looks strange) In my opinion its only when you start including the time and timezone in an ISO date or using less common variations of it that it starts to get confusing for humans (so I think there is a case for marking up times and timezones separately to the dates.) Regarding: screen readers - using words rather than numbers for the month (with a full four digit year) may seem like a good option until you start to consider how to handle those names in hundreds of different languages. ...perhaps if there was a way to define such names in the actual markup? ...but specifying formats, languages, etc in the markup would make it more complicated for authors. Given how often I've seen 'Z' misused in timezones I think making it simple for authoring is something worth considering too. From jonas.esp at googlemail.com Sun Sep 21 12:48:24 2008 From: jonas.esp at googlemail.com (Jonas) Date: Sun Sep 21 12:48:27 2008 Subject: [uf-discuss] Suggestion for Birthday Message-ID: <20cf13940809211248qb0b41ao9be3e9a4395d89ad@mail.gmail.com> The bday field is a problem since that many users want not enter the year. OpenID [1] solved it so: date of birth as YYYY-MM-DD. Any values whose representation uses fewer than the specified number of digits should be zero-padded. The length of this value MUST always be 10. If the End User user does not want to reveal any particular component of this value, it MUST be set to zero. For instance, if a End user wants to specify that his date of birth is in 1980, but not the month or day, the value returned SHALL be "1980-00-00". So the developers could let enter any of these options: "YYYY" (for year), "YYYY-mm" (year-month) or "mm-dd" (month-day), and a complete date. [1] http://openid.net/specs/openid-simple-registration-extension-1_1-01.html From mail at tobyinkster.co.uk Mon Sep 22 13:11:38 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Mon Sep 22 13:12:08 2008 Subject: [uf-discuss] Suggestion for Birthday Message-ID: <8FEC99F9-2C68-49B2-A3BA-F118D1292F98@tobyinkster.co.uk> With Microformats, dates are in ISO 8601 format. ISO 8601 already allows for years without months or days. e.g. 1980 And indeed with years and months, but no days: 1980-06 Most microformat parsers already support these, so no need to go inventing some non-ISO format. ISO 8601 also offers a way of specifying months and days without a year: --06-01 Though this doesn't have such wide support. -- Toby A Inkster From martin at weborganics.co.uk Tue Sep 23 15:56:33 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Tue Sep 23 15:56:41 2008 Subject: [uf-discuss] ISO Dates and Durations Message-ID: <48D97421.3080801@weborganics.co.uk> Hello all I have been playing (again) with a solution to data being expressed in titles. A workaround I have found is to use a kind of reverse include with the machine-data being pushed into the of your document example: 5.33 and in the head of your document you could have something like this: has any one any thoughts on this approach. Best Wishes Martin McEvoy From tantek at cs.stanford.edu Tue Sep 23 19:02:56 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Tue Sep 23 19:02:52 2008 Subject: [uf-discuss] Suggestion for Birthday In-Reply-To: <8FEC99F9-2C68-49B2-A3BA-F118D1292F98@tobyinkster.co.uk> References: <8FEC99F9-2C68-49B2-A3BA-F118D1292F98@tobyinkster.co.uk> Message-ID: <598692498-1222221756-cardhu_decombobulator_blackberry.rim.net-1461070727-@bxe118.bisx.prod.on.blackberry> Toby, Thanks for investigating this and documenting it. Could you add your research and answers to the hCard FAQ? http://microformats.org/wiki/hcard-faq Thanks, Tantek -----Original Message----- From: Toby A Inkster Date: Mon, 22 Sep 2008 21:11:38 To: Subject: [uf-discuss] Suggestion for Birthday With Microformats, dates are in ISO 8601 format. ISO 8601 already allows for years without months or days. e.g. 1980 And indeed with years and months, but no days: 1980-06 Most microformat parsers already support these, so no need to go inventing some non-ISO format. ISO 8601 also offers a way of specifying months and days without a year: --06-01 Though this doesn't have such wide support. -- Toby A Inkster _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From mail at ciaranmcnulty.com Wed Sep 24 01:37:17 2008 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Wed Sep 24 01:37:21 2008 Subject: [uf-discuss] ISO Dates and Durations In-Reply-To: <48D97421.3080801@weborganics.co.uk> References: <48D97421.3080801@weborganics.co.uk> Message-ID: On Tue, Sep 23, 2008 at 11:56 PM, Martin McEvoy wrote: > 5.33 > > and in the head of your document you could have something like this: > > > > has any one any thoughts on this approach. I have reservations about it, to be honest. If we're going to have hidden data (and frankly from what I can tell from discussions so far about this, we're heading that way) it's better that its 'near' the visible version in the HTML rather than being hidden in the HEAD. -Ciaran McNulty From martin at weborganics.co.uk Wed Sep 24 02:55:48 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Wed Sep 24 02:55:57 2008 Subject: [uf-discuss] ISO Dates and Durations In-Reply-To: References: <48D97421.3080801@weborganics.co.uk> Message-ID: <48DA0EA4.7020406@weborganics.co.uk> Ciaran McNulty wrote: > On Tue, Sep 23, 2008 at 11:56 PM, Martin McEvoy > wrote: > >> 5.33 >> >> and in the head of your document you could have something like this: >> >> >> >> has any one any thoughts on this approach. >> > > I have reservations about it, to be honest. If we're going to have > hidden data (and frankly from what I can tell from discussions so far > about this, we're heading that way) it's better that its 'near' the > visible version in the HTML rather than being hidden in the HEAD. > Thanks Ciaran, I agree it should be near the html version, the only question is how is that achieved now? I have seen plenty of Ideas mooted around the wiki, its just that no-one can agree a method, its faily important I would say that this issue be resolved in some way, Microformats cant wait around till 2022 for html5, I think it should be addressed here and now, and most people do not have any problems of putting machine data in the head of a document, for example service discovery links and meta details such as keywords and descriptions. its worth a little thought a think? Best Wishes Martin McEvoy > -Ciaran McNulty > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From loertsch.thomas at guj.de Wed Sep 24 07:33:34 2008 From: loertsch.thomas at guj.de (Thomas Loertsch) Date: Wed Sep 24 07:33:49 2008 Subject: [uf-discuss] hRecipe - one suggestion, a lot of comments Message-ID: Hi all, as I already posted here we're planning to implement hRecipe at "essen & trinken" [1]. I think hRecipe is in quite a good shape already. Cognition [2] has recently included "experimental support for the proposed hRecipe microformat" (though the document [3] is a bit vague about what exactly they make required and optional respectively). As I'm not sure (and most probably nobody is) how the standardisation process carries on, this experimaental support at least seems to be a viable option to get things moving. But it's also a reminder that there are some open issues which somehow have to be resolved. And maybe there isn't so much more to clear out? But before I give my comments to the open issues please let me open another one ;-) * Suggestion: idle period / off-time / rest period / unattended time You have to help me with the right english term here. What I mean is the time that i.e. the dough needs to rise. When scanning a recipe for practicality this is very important information. I'd like to suggest this as an optional element. Please comment! Now my 5 cents to the issues as summarized in recipe brainstorming [4]. I'm trying to comment on all open issues, to help sort things out: * Date published I would leave the use of the datetime-design-pattern as optional (should). Although it means stopping halfway by making the date machine retrievable but not machine readable it is still better then nothing. And the issues around datetime-design-pattern are not trivial. * Ingredient TobyInk proposes an optimization for Ingredient which makes sense, but... first I wonder how much harder the optimization makes it to develop parsers. And second the rule should be extended: if there is no , IS the AND there cannot be any further , or for that ingredient. All in all that sounds too complex to me, an accomplishment not worth the effort and therefor not in alignement with the 80/20 principal. So I'm against it (not violently, though). * Method TobyInk proposes to make the method optional. Although most recipes rely heavily on a method there are indeed those where it isn't necessary. If 80/20 does mean that easy or simple usecases should be facilitated it would be in line with the principal to make the method optional. Since making it optional doesn't hurt anybody I agree with TobyInks proposal. * Suggested: Method > Steps or Method-Step I'm against that. Outside 80/20. xHTML can do that alright. Also see below. * Suggested: Calories I'm all for that. Our site has nutritional information for calories, proteins, carbohydrates and fat. That's also what european law demands as information on packaged food. Most sites that I visited only listed calories as nutritional information if they did at all. Allrecipes.com is the other extreme with a huge list of nutritional information - clearly outside 80/20 imho. Calories are a superordinate concept for proteins, carbohydrates and fat. Nuitritional information is quite important for a lot of people. I think calories are inside the 80/20 and should be included as an optional element. A minor issue though: calories or joule? Most sites use Calories, but the term is deprecated, and hMeasure uses Joule. * Measure / use of hMeasure There are a lot of units typically used in recipes that do not make much sense in most other cases and therefor most likely will never make it into a 80/20-aware measure-microformat. This is a deliberatly short list: - glass - leave - pinch - tablespoonful - teaspoonful - lacing - tie (??? my english is really leaving me here, hope you get the idea) can be used to indicate more subtle differentiation (like a "big spoonful", "some leaves" etc). I think this list is both usefully short and complete. The following measures - weight (gram) - volume (litre) - length (metre) can be taken from the measure microformat. I guess measure is already stable enough that it's save to use these terms "experimentally". The measure-element should be optional. That way nobody is forced to select a value from it - it's just a help to facilitate interoperability. * Note Note should stay as an optional value. There are so many ways to define ingredients that it seems usefull enough to fit into the 80/20. And it's a necessary addition to the proposed measurement-values above. * Additional Suggestions - Steps, Ingredient Grouping have both received negative feedback in comments. I could imagine a node, together with a being useful for ingredients as well as for steps (or authors or...). But wouldn't that better be handled by another microformat? XOXO? Or by @section of HTML5? * Additional Suggestions - Diffculty/Notes, Suitability I'd rather not include these. Too diverse in the wild, better handled by tags (at least in the first version). * Scope There seems to be a consensus that this is out of scope. Should be closed as an issue. * Single foodstuffs make no sense imho. Should be closed as an issue. * Menus I would consider this out of scope too. Should be closed as an issue * Multiple Items per Ingredient I don't understand the problem. Since we're talking about free form text entry fields you can easily define one item "salt and sugar" or two items "salt", "sugar". Options can be noted in the field. Okay, hope this helps in advancing the format. Please give feedback! Regards, Thomas [1] http://microformats.org/discuss/mail/microformats-discuss/2008-September/012 461.html [2] http://buzzword.org.uk/cognition/ [3] http://buzzword.org.uk/cognition/uf-plus.html#hrecipe [4] http://microformats.org/wiki/recipe-brainstorming . Thomas L?rtsch Living at Home Multi Media GmbH Redaktion Online .. Stubbenhuk 5 20459 Hamburg ... eMail: loertsch.thomas@guj.de From jonas.esp at googlemail.com Wed Sep 24 12:58:58 2008 From: jonas.esp at googlemail.com (Jonas) Date: Wed Sep 24 12:59:00 2008 Subject: [uf-discuss] Indicate order of sub-properties Message-ID: <20cf13940809241258u2900d8d4qcac3864f1c6ec78@mail.gmail.com> Since each country has a different order to show data related to addresses and names, I think that would be necessary and very useful for full localization that would be a property or sub-property to indicate that order of sub-properties. From jonas.esp at googlemail.com Wed Sep 24 12:47:15 2008 From: jonas.esp at googlemail.com (Jonas) Date: Wed Sep 24 13:16:29 2008 Subject: [uf-discuss] gender Message-ID: <20cf13940809241247t678148f3k19273af7ab61726c@mail.gmail.com> I made in lack a property as 'gender' representing the gender of a person. In most cases the value would be the string 'female' or 'male'. From mail at tobyinkster.co.uk Wed Sep 24 13:32:43 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Sep 24 13:33:16 2008 Subject: [uf-discuss] Indicate order of sub-properties Message-ID: In some cultures (e.g. China), full names are written in family-name given-name order, whereas in others (e.g. Western Europe), given-name family-name is used. So you might think it would be nice if we had a way to indicate the order of properties within "n", but in actual fact, we don't need it - "fn" provides us with the name with all its parts in the correct order. Similarly, "label" provides a fully-formatted address, with all its components in the right order. -- Toby A Inkster From tantek at cs.stanford.edu Wed Sep 24 13:35:31 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Wed Sep 24 14:05:57 2008 Subject: [uf-discuss] Indicate order of sub-properties In-Reply-To: References: Message-ID: <738533378-1222288512-cardhu_decombobulator_blackberry.rim.net-260391131-@bxe118.bisx.prod.on.blackberry> Toby, this too is a good answer that should be in the hCard FAQ (if it isn't already). Thanks! Tantek -----Original Message----- From: Toby A Inkster Date: Wed, 24 Sep 2008 21:32:43 To: Subject: [uf-discuss] Indicate order of sub-properties In some cultures (e.g. China), full names are written in family-name given-name order, whereas in others (e.g. Western Europe), given-name family-name is used. So you might think it would be nice if we had a way to indicate the order of properties within "n", but in actual fact, we don't need it - "fn" provides us with the name with all its parts in the correct order. Similarly, "label" provides a fully-formatted address, with all its components in the right order. -- Toby A Inkster _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From mail at tobyinkster.co.uk Wed Sep 24 14:07:36 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed Sep 24 14:08:09 2008 Subject: [uf-discuss] hRecipe - one suggestion, a lot of comments Message-ID: Thomas Loertsch wrote: > as I already posted here we're planning to implement hRecipe at > "essen & > trinken" [1]. I think hRecipe is in quite a good shape already. > Cognition > [2] has recently included "experimental support for the proposed > hRecipe > microformat" (though the document [3] is a bit vague about what > exactly they > make required and optional respectively). I've put together slightly better documentation of Cognition's support for it here: http://buzzword.org.uk/cognition/uf-plus.html#hrecipe > * Suggestion: idle period / off-time / rest period / unattended time Perhaps preparation-time could be made into a plural type+value property (like "tel" in hCard). Preparation: 10 mins Waiting: 25 mins Cooking: 35 mins > TobyInk proposes an optimization for Ingredient which makes sense, > but... > first I wonder how much harder the optimization makes it to develop > parsers. It's very little effort to implement, but saves a lot of typing when publishing recipes, especially when there are a lot of ingredients. Implementation is easy by just performing a tiny pre-processing step. (Code below in Javascript, assumes that the hRecipe root element is "hroot". Should be very easy to port to other DOM-compatible languages.) var nodes = hroot.getElementsByClassName('ingredients'); for (var i=0; nodes[i]; i++) { var kids = nodes[i].getChildrenByTagName('*'); for (var j=0; kids[j]; j++) { kids[j].className += " ingredient"; } } Pretty easy. And if you think it's a bit messy to change the DOM tree prior to parsing, you should realise that most parsers make a lot of DOM changes prior to the proper parsing stage in order to implement the include pattern. -- Toby A Inkster From philip.tellis at gmail.com Wed Sep 24 17:54:14 2008 From: philip.tellis at gmail.com (Philip Tellis) Date: Wed Sep 24 17:54:17 2008 Subject: [uf-discuss] ISO Dates and Durations In-Reply-To: <48DA0EA4.7020406@weborganics.co.uk> References: <48D97421.3080801@weborganics.co.uk> <48DA0EA4.7020406@weborganics.co.uk> Message-ID: <2e95f9b80809241754x4ff50b85o2fa91370cc4cf29@mail.gmail.com> 2008/9/24 Martin McEvoy : > people do not have any problems of putting machine data in the head of a > document, for example service discovery links and meta details such as > keywords and descriptions. its worth a little thought a think? >From a performance point of view, dumping too much user invisible data into the HEAD section of the document is going to eat up bytes that are of no use to most users. Personally, I'd leave the HEAD for data that the browser needs up front in order to correctly render the page (eg: CSS, favicon, content-type, link-rel), and push everything else lower down to when it's actually needed. However, keep in mind that one size doesn't fit all. Going too far on the performance scale can sometimes mean a loss of validity, accessibility, and semantic value, so it's up to individual site owners to make the call. We should provide a couple of options that touch different points on this scale. From jonas.esp at googlemail.com Thu Sep 25 01:50:52 2008 From: jonas.esp at googlemail.com (Jonas) Date: Thu Sep 25 01:50:56 2008 Subject: [uf-discuss] Indicate order of sub-properties In-Reply-To: References: Message-ID: <20cf13940809250150x4088a7e2q508b777fed41362c@mail.gmail.com> The problem is that you are repeating the same information. Using *n* and *fn* you repite it two times, and if use label you're repeating it until *three times* for each user. This is not optimal. However if you have a field where to indicate the order, this could be used for all users of a same country (as minimum). 2008/9/24 Toby A Inkster : > In some cultures (e.g. China), full names are written in family-name > given-name order, whereas in others (e.g. Western Europe), given-name > family-name is used. So you might think it would be nice if we had a way to > indicate the order of properties within "n", but in actual fact, we don't > need it - "fn" provides us with the name with all its parts in the correct > order. > > Similarly, "label" provides a fully-formatted address, with all its > components in the right order. From martin at weborganics.co.uk Thu Sep 25 02:16:19 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Sep 25 02:16:26 2008 Subject: [uf-discuss] ISO Dates and Durations In-Reply-To: <2e95f9b80809241754x4ff50b85o2fa91370cc4cf29@mail.gmail.com> References: <48D97421.3080801@weborganics.co.uk> <48DA0EA4.7020406@weborganics.co.uk> <2e95f9b80809241754x4ff50b85o2fa91370cc4cf29@mail.gmail.com> Message-ID: <48DB56E3.8040104@weborganics.co.uk> Hello Philip Philip Tellis wrote: > 2008/9/24 Martin McEvoy : > > >> people do not have any problems of putting machine data in the head of a >> document, for example service discovery links and meta details such as >> keywords and descriptions. its worth a little thought a think? >> > > >From a performance point of view, dumping too much user invisible data > into the HEAD section of the document is going to eat up bytes that > are of no use to most users. Agreed... > Personally, I'd leave the HEAD for data > that the browser needs up front in order to correctly render the page > (eg: CSS, favicon, content-type, link-rel), Machine Data also like service discovery links, alternate formats such as RDF Atom and RSS, a vast amount of websites also use meta tags for verification such as microid an Google Analytics also for Descriptions and keywords, how many websites in the web2.0 world have you seen using external Javascript? this has to be loaded into the browser too, so where performance is concerned pushing a few extra bits of data up into the head is really a non-issue to most. Pushing data up into the head (for machines) would seem like the right place to put ISO durations and timestamps to separate content from data. > and push everything else > lower down to when it's actually needed. > > However, keep in mind that one size doesn't fit all. Going too far on > the performance scale can sometimes mean a loss of validity, > accessibility, and semantic value, .... > so it's up to individual site > owners to make the call. We should provide a couple of options that > touch different points on this scale. > Agreed Thank you Martin McEvoy > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From brian.suda at gmail.com Thu Sep 25 02:38:02 2008 From: brian.suda at gmail.com (Brian Suda) Date: Thu Sep 25 02:38:06 2008 Subject: [uf-discuss] Indicate order of sub-properties In-Reply-To: <20cf13940809250150x4088a7e2q508b777fed41362c@mail.gmail.com> References: <20cf13940809250150x4088a7e2q508b777fed41362c@mail.gmail.com> Message-ID: <21e770780809250238q3f38d3a0r365a75b17d2a9a2@mail.gmail.com> On 9/25/08, Jonas wrote: > The problem is that you are repeating the same information. Using *n* > and *fn* you repite it two times, and if use label you're repeating it > until *three times* for each user. This is not optimal. > > However if you have a field where to indicate the order, this could be > used for all users of a same country (as minimum). can you give us a concrete example or a link to an example you need to mark-up. Then we can discuss how it is possible to mark-up the information. We might be talking about the same thing without realizing it. Thanks, -brian -- brian suda http://suda.co.uk From martin at weborganics.co.uk Thu Sep 25 02:49:51 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Thu Sep 25 02:49:58 2008 Subject: [uf-discuss] ISO Dates and Durations In-Reply-To: <48DB56E3.8040104@weborganics.co.uk> References: <48D97421.3080801@weborganics.co.uk> <48DA0EA4.7020406@weborganics.co.uk> <2e95f9b80809241754x4ff50b85o2fa91370cc4cf29@mail.gmail.com> <48DB56E3.8040104@weborganics.co.uk> Message-ID: <48DB5EBF.2000906@weborganics.co.uk> Martin McEvoy wrote: > Machine Data also like service discovery links, alternate formats such > as RDF Atom and RSS, a vast amount of websites also use meta tags for > verification such as microid an Google Analytics also for Descriptions > and keywords, how many websites in the web2.0 world have you seen > using external Javascript? this has to be loaded into the browser too, > so where performance is concerned pushing a few extra bits of data up > into the head is really a non-issue to most. Pushing data up into the > head (for machines) would seem like the right place to put ISO > durations and timestamps to separate content from data. A side note to this People also publish ISO date-times in the HEAD of their documents a little more than you may at first think, how many times has anyone seen markup like this: see also for an examples: http://www.w3.org/TR/REC-html40/struct/global.html#h-7.4.4.3 http://www.google.com/search?hl=en&q=meta+name%3D%22date%22 Thanks Martin McEvoy From jonas.esp at googlemail.com Thu Sep 25 03:29:20 2008 From: jonas.esp at googlemail.com (Jonas) Date: Thu Sep 25 03:29:23 2008 Subject: [uf-discuss] Indicate order of sub-properties In-Reply-To: <21e770780809250238q3f38d3a0r365a75b17d2a9a2@mail.gmail.com> References: <20cf13940809250150x4088a7e2q508b777fed41362c@mail.gmail.com> <21e770780809250238q3f38d3a0r365a75b17d2a9a2@mail.gmail.com> Message-ID: <20cf13940809250329r43d0958eo7db99f9faf05b28@mail.gmail.com> As example: --------------- N:Santana,P?rez;Carlos;;D.; FN:D. Carlos Santana P?rez ADR;TYPE=dom,home,postal,parcel:;;C/ Manuel, n?5, 3C;Flandes;Murcia;31456;Spain LABEL;TYPE=dom,home,postal,parcel:D. Carlos Santana P?rez\nC/ Manuel, n?5, 3C\n31456 - Flandes\nMurcia\nSpain --------------- I don't see logical neither optimal that the user have to write the same information 2 times for both name and address. He wants anything simple, aside he/she is customary to write it according to the form to do it in its country (locale). If this is unknown, then there will be two direct consequences, the user will not introduce these data or they been entered of incorrect form, which will be the same since that we will not have trustworthy data. 2008/9/25 Brian Suda : > On 9/25/08, Jonas wrote: >> The problem is that you are repeating the same information. Using *n* >> and *fn* you repite it two times, and if use label you're repeating it >> until *three times* for each user. This is not optimal. >> >> However if you have a field where to indicate the order, this could be >> used for all users of a same country (as minimum). > > can you give us a concrete example or a link to an example you need to > mark-up. Then we can discuss how it is possible to mark-up the > information. We might be talking about the same thing without > realizing it. From brian.suda at gmail.com Thu Sep 25 03:53:51 2008 From: brian.suda at gmail.com (Brian Suda) Date: Thu Sep 25 03:53:56 2008 Subject: [uf-discuss] Indicate order of sub-properties In-Reply-To: <20cf13940809250329r43d0958eo7db99f9faf05b28@mail.gmail.com> References: <20cf13940809250150x4088a7e2q508b777fed41362c@mail.gmail.com> <21e770780809250238q3f38d3a0r365a75b17d2a9a2@mail.gmail.com> <20cf13940809250329r43d0958eo7db99f9faf05b28@mail.gmail.com> Message-ID: <21e770780809250353h2908acbao7d7039cc210861c1@mail.gmail.com> On Thu, Sep 25, 2008 at 10:29 AM, Jonas wrote: > As example: > > --------------- > N:Santana,P?rez;Carlos;;D.; > FN:D. Carlos Santana P?rez > > ADR;TYPE=dom,home,postal,parcel:;;C/ Manuel, n?5, 3C;Flandes;Murcia;31456;Spain > > LABEL;TYPE=dom,home,postal,parcel:D. Carlos Santana P?rez\nC/ Manuel, > n?5, 3C\n31456 - Flandes\nMurcia\nSpain > --------------- > I don't see logical neither optimal that the user have to write the > same information 2 times for both name and address. He wants anything > simple, aside he/she is customary to write it according to the form to > do it in its country (locale). D. Carlos Santana P?rez Because N has several sub-properties, you can order those in any way that you want. FN will take the string as they are ordered in the HTML, but N will re-order them as needed. The same applies to addresses as well. -brian -- brian suda http://suda.co.uk From loertsch.thomas at guj.de Thu Sep 25 06:24:10 2008 From: loertsch.thomas at guj.de (Thomas Loertsch) Date: Thu Sep 25 06:24:18 2008 Subject: [uf-discuss] hRecipe - one suggestion, a lot of comments In-Reply-To: Message-ID: Hi, On 24.09.08 23:07, "Toby A Inkster" wrote: > I've put together slightly better documentation of Cognition's > support for it here: > > http://buzzword.org.uk/cognition/uf-plus.html#hrecipe slightly ;-) Very impressive work, btw! >> * Suggestion: idle period / off-time / rest period / unattended time > > > Perhaps preparation-time could be made into a plural type+value > property (like "tel" in hCard). > > > Preparation: > 10 mins > > > Waiting: > 25 mins > > > Cooking: > 35 mins > That's an idea. Would it mean that we have to develop a vocabulary of types or would that be freeform? In the latter case and to avoid developing another sub-vocabulary respectively how about this: * preparation-time (optional, plural) ** preparation-time-note (optional, singular) In prose: there can be more then one preparation-time element and each can have a note inline. That way it would be clear that we don't develop a sub-vocabulary. Editing would be easy (just leave it out if you don't need it). Parsing is easy too. I would prefer that solution as a middle ground, but let's at least make preparation-time plural. Anything else might as well fall outside the 80/20. >> TobyInk proposes an optimization for Ingredient which makes sense, >> but... >> first I wonder how much harder the optimization makes it to develop >> parsers. > > > It's very little effort to implement, but saves a lot of typing when > publishing recipes, especially when there are a lot of ingredients. > Implementation is easy by just performing a tiny pre-processing step. > (Code below in Javascript, assumes that the hRecipe root element is > "hroot". Should be very easy to port to other DOM-compatible languages.) > > var nodes = hroot.getElementsByClassName('ingredients'); > for (var i=0; nodes[i]; i++) > { > var kids = nodes[i].getChildrenByTagName('*'); > for (var j=0; kids[j]; j++) > { kids[j].className += " ingredient"; } > } > > Pretty easy. And if you think it's a bit messy to change the DOM tree > prior to parsing, you should realise that most parsers make a lot of > DOM changes prior to the proper parsing stage in order to implement > the include pattern. Okay, parsing indeed seems to not be an issue, but I'm still not convinced that it's wise to introduce variations in the syntax for the single most important element (beside the title). Also the case seems very rare to me. I just checked a couple of our recipes to be sure and I couldn't find any case where there was an item without some quantity or note attached. We might be overly pedantic though ;-) Can you give some examples? Cheers, Thomas Thomas L?rtsch Business Development _________________________________________________________ Living at Home Multi Media GmbH Redaktion Online Stubbenhuk 5 20459 Hamburg Postanschrift: 20444 Hamburg Telefon +49 (0) 40 / 37 03 - 43 14 Telefax +49 (0) 40 / 37 03 - 42 12 E-Mail loertsch.thomas@guj.de http://www.livingathome.de http://www.essen-und-trinken.de http://www.dogs-magazin.de http://www.wiewohnstdu.de _________________________________________________________ Living at Home Multi Media GmbH | Sitz: Hamburg, Amtsgericht Hamburg HRB 75612 | Gesch?ftsf?hrer: Thomas Lindner, Nadja Stavenhagen | Ein Unternehmen von Gruner + Jahr From tantek at cs.stanford.edu Thu Sep 25 11:23:47 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Thu Sep 25 11:23:36 2008 Subject: [uf-discuss] Indicate order of sub-properties In-Reply-To: <21e770780809250353h2908acbao7d7039cc210861c1@mail.gmail.com> References: <20cf13940809250150x4088a7e2q508b777fed41362c@mail.gmail.com><21e770780809250238q3f38d3a0r365a75b17d2a9a2@mail.gmail.com><20cf13940809250329r43d0958eo7db99f9faf05b28@mail.gmail.com><21e770780809250353h2908acbao7d7039cc210861c1@mail.gmail.com> Message-ID: <292121486-1222367009-cardhu_decombobulator_blackberry.rim.net-1652976720-@bxe118.bisx.prod.on.blackberry> Brian, I think is a very important clarification that may not be obvious to everyone from reading the hCard/vCard docs. Could you add your answer and explanation to the hCard FAQ? http://microformats.org/wiki/hcard-faq Thanks! Tantek -----Original Message----- From: "Brian Suda" Date: Thu, 25 Sep 2008 10:53:51 To: Microformats Discuss Subject: Re: [uf-discuss] Indicate order of sub-properties On Thu, Sep 25, 2008 at 10:29 AM, Jonas wrote: > As example: > > --------------- > N:Santana,P?rez;Carlos;;D.; > FN:D. Carlos Santana P?rez > > ADR;TYPE=dom,home,postal,parcel:;;C/ Manuel, n?5, 3C;Flandes;Murcia;31456;Spain > > LABEL;TYPE=dom,home,postal,parcel:D. Carlos Santana P?rez\nC/ Manuel, > n?5, 3C\n31456 - Flandes\nMurcia\nSpain > --------------- > I don't see logical neither optimal that the user have to write the > same information 2 times for both name and address. He wants anything > simple, aside he/she is customary to write it according to the form to > do it in its country (locale). D. Carlos Santana P?rez Because N has several sub-properties, you can order those in any way that you want. FN will take the string as they are ordered in the HTML, but N will re-order them as needed. The same applies to addresses as well. -brian -- brian suda http://suda.co.uk _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From jonas.esp at googlemail.com Fri Sep 26 12:43:28 2008 From: jonas.esp at googlemail.com (Jonas) Date: Fri Sep 26 12:43:31 2008 Subject: [uf-discuss] gender Message-ID: <20cf13940809261243r21b26830gecfb122bf25b001@mail.gmail.com> 2008/9/24 Jonas : > I made in lack a property as 'gender' representing the gender of a > person. In most cases the value would be the string 'female' or > 'male'. I found some interesting additional properties which have too 'gender': http://buzzword.org.uk/cognition/uf-plus.html#hcard From brian.suda at gmail.com Fri Sep 26 13:17:07 2008 From: brian.suda at gmail.com (Brian Suda) Date: Fri Sep 26 13:17:12 2008 Subject: [uf-discuss] gender In-Reply-To: <20cf13940809261243r21b26830gecfb122bf25b001@mail.gmail.com> References: <20cf13940809261243r21b26830gecfb122bf25b001@mail.gmail.com> Message-ID: <21e770780809261317v6fda1c0er9d922504a4db25e7@mail.gmail.com> On 9/26/08, Jonas wrote: > 2008/9/24 Jonas : > > > I made in lack a property as 'gender' representing the gender of a > > person. In most cases the value would be the string 'female' or > > 'male'. There is an FAQ on the wiki about this. http://microformats.org/wiki/hcard-faq#How_is_gender_represented -brian -- brian suda http://suda.co.uk From jonas.esp at googlemail.com Sat Sep 27 03:23:02 2008 From: jonas.esp at googlemail.com (Jonas) Date: Sat Sep 27 03:23:04 2008 Subject: [uf-discuss] gender In-Reply-To: <21e770780809261317v6fda1c0er9d922504a4db25e7@mail.gmail.com> References: <20cf13940809261243r21b26830gecfb122bf25b001@mail.gmail.com> <21e770780809261317v6fda1c0er9d922504a4db25e7@mail.gmail.com> Message-ID: <20cf13940809270323j489d271eubeb28ab9fb84654a@mail.gmail.com> I prefer use it as it is indicated in the vCard 4.0 draft [1]. In addition there are another new properties which I am interested as LANG, IMPP or KIND. http://tools.ietf.org/html/draft-resnick-vcarddav-vcardrev-01 2008/9/26 Brian Suda : > On 9/26/08, Jonas wrote: >> 2008/9/24 Jonas : >> >> > I made in lack a property as 'gender' representing the gender of a >> > person. In most cases the value would be the string 'female' or >> > 'male'. > > There is an FAQ on the wiki about this. > > http://microformats.org/wiki/hcard-faq#How_is_gender_represented > > -brian > > -- > brian suda > http://suda.co.uk > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From mail at tobyinkster.co.uk Sat Sep 27 07:03:39 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sat Sep 27 07:04:17 2008 Subject: [uf-discuss] gender Message-ID: <6A2132CE-A923-46A4-AED3-D4BF1CCCD6F8@tobyinkster.co.uk> Jonas wrote: > I prefer use it as it is indicated in the vCard 4.0 draft [1]. In > addition there are another new properties which I am interested as > LANG, IMPP or KIND. > > http://tools.ietf.org/html/draft-resnick-vcarddav-vcardrev-01 Latest version of the vCard 4.0 draft is here: http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-03 There is nothing to stop you using these in hCards, but you should be aware that most parsers will ignore them - just as they'd ignore class="foobar" or class="xyzzy" - they'd be assumed to be non-hCard classes added for presenational or other reasons. Cognition does support these vCard 4.0 properties as an experimental extension (and various others - for instance, CALURI is cool), and although hCard is officially based on vCard 3.0 it seems very likely that if ever a new version of hCard were to be decided upon, new classes would be chosen to be compatible with new versions of vCard. In the mean time you can always combine them with other (existing) hCard classes to get the best of both worlds. e.g. Male individual jab me -- Toby A Inkster From martin at weborganics.co.uk Sat Sep 27 12:43:19 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Sep 27 12:43:28 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <48DB5EBF.2000906@weborganics.co.uk> References: <48D97421.3080801@weborganics.co.uk> <48DA0EA4.7020406@weborganics.co.uk> <2e95f9b80809241754x4ff50b85o2fa91370cc4cf29@mail.gmail.com> <48DB56E3.8040104@weborganics.co.uk> <48DB5EBF.2000906@weborganics.co.uk> Message-ID: <48DE8CD7.2090809@weborganics.co.uk> Hello all Something caught my eye when I was investigating resolutions for the abbr-design-pattern "...Any style sheet language may be used with HTML. A simple style sheet language may suffice for the needs of most users, but other languages may be more suited to highly specialized needs..."[1] [1] http://www.w3.org/TR/REC-html40/present/styles.html#h-14.2 If any style sheet language can be used, why don't microformats create their own style language eg: 4th Jan, 1968 or something similar, parsers can just as easily determine values from @style as they can any other property. Thanks Martin McEvoy From csarven at gmail.com Sat Sep 27 13:40:35 2008 From: csarven at gmail.com (Sarven Capadisli) Date: Sat Sep 27 13:40:37 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <48DE8CD7.2090809@weborganics.co.uk> References: <48D97421.3080801@weborganics.co.uk> <48DA0EA4.7020406@weborganics.co.uk> <2e95f9b80809241754x4ff50b85o2fa91370cc4cf29@mail.gmail.com> <48DB56E3.8040104@weborganics.co.uk> <48DB5EBF.2000906@weborganics.co.uk> <48DE8CD7.2090809@weborganics.co.uk> Message-ID: On Sat, Sep 27, 2008 at 3:43 PM, Martin McEvoy wrote: > If any style sheet language can be used, why don't microformats create their > own style language eg: > > 4th Jan, 1968 > > or something similar, parsers can just as easily determine values from > @style as they can any other property. Interesting. For HTML 4, AFAIK, the intention of a style sheet language is to provide a way to *present* an existing structure. It is not meant to bring in additional structure or semantics. Having said that, this is not the case in XHTML 1 with XSLT. I may be misinterpreting and so it would be nice to hear what everyone else have to say about this. Creating a style sheet language just for microformats goes out of the way of trying to work within existing standards. If we were to say okay to this, I'm sure there are plenty of ways where we could extend the representation of microformats (which will most likely go against the principles). Placing data that is intended for the machines inside @style is bound to run into the same arguments against @title (even though I don't personally believe the information in @title is intended for machines) -Sarven From mail at tobyinkster.co.uk Sat Sep 27 15:27:02 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sat Sep 27 15:27:32 2008 Subject: [uf-discuss] ISO Dates and Durations using Style Message-ID: <55AC3460-9DFE-4121-9A5B-77207A58BDCE@tobyinkster.co.uk> > If any style sheet language can be used, why don't microformats create > their own style language eg: > 4th Jan, 1968 By definition, the contents of the style attribute must be in "the default style sheet language". The default style sheet language is by definition CSS unless a Content-Style-Type header (either HTTP header or ) is present. There can only be one default style sheet language per document, thus any document which wants to use a non-CSS style sheet language in the style attribute cannot use CSS in the style attribute. (That is, you can't use CSS in some style attributes and non-CSS on others.) -- Toby A Inkster From tantek at cs.stanford.edu Sat Sep 27 15:55:33 2008 From: tantek at cs.stanford.edu (Tantek Celik) Date: Sat Sep 27 15:55:25 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <55AC3460-9DFE-4121-9A5B-77207A58BDCE@tobyinkster.co.uk> References: <55AC3460-9DFE-4121-9A5B-77207A58BDCE@tobyinkster.co.uk> Message-ID: <53931961-1222556117-cardhu_decombobulator_blackberry.rim.net-284436901-@bxe118.bisx.prod.on.blackberry> I agree with Toby's assessment. In addition to violating the semantic (presentation vs data) of the style attribute, web designers still very often use the style attribute for spot styling which implies/requires that the default styling language be CSS. Toby your answer is very well worded and would be a good start for a "rejected-syntaxes" page. http://microformats.org/wiki/rejected-syntaxes Thanks, Tantek -----Original Message----- From: Toby A Inkster Date: Sat, 27 Sep 2008 23:27:02 To: Subject: [uf-discuss] ISO Dates and Durations using Style > If any style sheet language can be used, why don't microformats create > their own style language eg: > 4th Jan, 1968 By definition, the contents of the style attribute must be in "the default style sheet language". The default style sheet language is by definition CSS unless a Content-Style-Type header (either HTTP header or ) is present. There can only be one default style sheet language per document, thus any document which wants to use a non-CSS style sheet language in the style attribute cannot use CSS in the style attribute. (That is, you can't use CSS in some style attributes and non-CSS on others.) -- Toby A Inkster _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From scott at randomchaos.com Sat Sep 27 17:22:46 2008 From: scott at randomchaos.com (Scott Reynen) Date: Sat Sep 27 17:22:54 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <55AC3460-9DFE-4121-9A5B-77207A58BDCE@tobyinkster.co.uk> References: <55AC3460-9DFE-4121-9A5B-77207A58BDCE@tobyinkster.co.uk> Message-ID: <925A648E-35D3-4224-98F3-FDB84ACB67B4@randomchaos.com> On [Sep 27], at [ Sep 27] 4:27 , Toby A Inkster wrote: >> If any style sheet language can be used, why don't microformats >> create >> their own style language eg: >> 4th Jan, 1968 > > By definition, the contents of the style attribute must be in "the > default style sheet language". The default style sheet language is > by definition CSS unless a Content-Style-Type header (either HTTP > header or ) is present. There can only be one > default style sheet language per document, thus any document which > wants to use a non-CSS style sheet language in the style attribute > cannot use CSS in the style attribute. (That is, you can't use CSS > in some style attributes and non-CSS on others.) That's certainly a reason not to make this a recommendation for everyone, but as we already have two alternative methods (machine data as human data and abbr-design-pattern), I'm not convinced we should discount this idea altogether. Conflict with CSS is only an issue with inline CSS, which is widely regarded as a poor practice anyway, especially among publishers paying enough attention to have concerns about the abbr-design-pattern. And it may not even be an issue there, as CSS says user agents "must ignore declarations with invalid values." [1] I'm afraid we may be dismissing this too hastily. My initial reaction to this idea was to view it as semantic abuse of the style attribute, but after thinking about it more, I now think it makes a lot of sense that "1968-01-04" should be treated as styling instructions for "4th Jan, 1968." We already have different kinds of styling instructions in CSS (i.e. visual, aural, and physical). I'd argue that this is a simply another type of instruction, context-dependent, just as much explaining how the content should be presented, e.g. it should be presented in whatever way ISO 8601 dates are presented in a given context. There may be good reasons this won't work, but I don't think the fact that no one has previously used @style for anything other than CSS is one of them. After all, the same was widely true of @class before we started promoting the alternative uses allowed under the HTML spec. [1] http://www.w3.org/TR/CSS21/conform.html#conformance Peace, Scott From martin at weborganics.co.uk Sat Sep 27 17:32:45 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Sep 27 17:32:53 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <53931961-1222556117-cardhu_decombobulator_blackberry.rim.net-284436901-@bxe118.bisx.prod.on.blackberry> References: <55AC3460-9DFE-4121-9A5B-77207A58BDCE@tobyinkster.co.uk> <53931961-1222556117-cardhu_decombobulator_blackberry.rim.net-284436901-@bxe118.bisx.prod.on.blackberry> Message-ID: <48DED0AD.9090702@weborganics.co.uk> Hello Tantek, Toby Tantek Celik wrote: > I agree with Toby's assessment. In addition to violating the semantic (presentation vs data) of the style attribute, web designers still very often use the style attribute for spot styling which implies/requires that the default styling language be CSS. > No Tantek and Toby you are misguided in your interpretation please cite your sources ... "This specification doesn't tie HTML to any particular style sheet language. This allows for a range of such languages to be used, for instance simple ones for the majority of users and much more complex ones for the minority of users with highly specialized needs. The examples included below all use the CSS (Cascading Style Sheets) language [CSS1], but other style sheet languages would be possible."[1] [1] http://www.w3.org/TR/REC-html40/present/styles.html#h-14.1 > Toby your answer is very well worded and would be a good start for a "rejected-syntaxes" page. > > http://microformats.org/wiki/rejected-syntaxes > No Toby don't this is a valid solution. Best wishes Martin McEvoy > Thanks, > > Tantek > > -----Original Message----- > From: Toby A Inkster > > Date: Sat, 27 Sep 2008 23:27:02 > To: > Subject: [uf-discuss] ISO Dates and Durations using Style > > > >> If any style sheet language can be used, why don't microformats create >> their own style language eg: >> 4th Jan, 1968 >> > > By definition, the contents of the style attribute must be in "the > default style sheet language". The default style sheet language is by > definition CSS unless a Content-Style-Type header (either HTTP header > or ) is present. There can only be one default style > sheet language per document, thus any document which wants to use a > non-CSS style sheet language in the style attribute cannot use CSS in > the style attribute. (That is, you can't use CSS in some style > attributes and non-CSS on others.) > > From martin at weborganics.co.uk Sat Sep 27 17:32:51 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Sep 27 17:32:58 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <53931961-1222556117-cardhu_decombobulator_blackberry.rim.net-284436901-@bxe118.bisx.prod.on.blackberry> References: <55AC3460-9DFE-4121-9A5B-77207A58BDCE@tobyinkster.co.uk> <53931961-1222556117-cardhu_decombobulator_blackberry.rim.net-284436901-@bxe118.bisx.prod.on.blackberry> Message-ID: <48DED0B3.10205@weborganics.co.uk> Hello Tantek, Toby Tantek Celik wrote: > I agree with Toby's assessment. In addition to violating the semantic (presentation vs data) of the style attribute, web designers still very often use the style attribute for spot styling which implies/requires that the default styling language be CSS. > No Tantek and Toby you are misguided in your interpretation please cite your sources ... "This specification doesn't tie HTML to any particular style sheet language. This allows for a range of such languages to be used, for instance simple ones for the majority of users and much more complex ones for the minority of users with highly specialized needs. The examples included below all use the CSS (Cascading Style Sheets) language [CSS1], but other style sheet languages would be possible."[1] [1] http://www.w3.org/TR/REC-html40/present/styles.html#h-14.1 > Toby your answer is very well worded and would be a good start for a "rejected-syntaxes" page. > > http://microformats.org/wiki/rejected-syntaxes > No Toby don't this is a valid solution. Best wishes Martin McEvoy > Thanks, > > Tantek > > -----Original Message----- > From: Toby A Inkster > > Date: Sat, 27 Sep 2008 23:27:02 > To: > Subject: [uf-discuss] ISO Dates and Durations using Style > > > >> If any style sheet language can be used, why don't microformats create >> their own style language eg: >> 4th Jan, 1968 >> > > By definition, the contents of the style attribute must be in "the > default style sheet language". The default style sheet language is by > definition CSS unless a Content-Style-Type header (either HTTP header > or ) is present. There can only be one default style > sheet language per document, thus any document which wants to use a > non-CSS style sheet language in the style attribute cannot use CSS in > the style attribute. (That is, you can't use CSS in some style > attributes and non-CSS on others.) > > From martin at weborganics.co.uk Sat Sep 27 17:39:05 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sat Sep 27 17:39:13 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <925A648E-35D3-4224-98F3-FDB84ACB67B4@randomchaos.com> References: <55AC3460-9DFE-4121-9A5B-77207A58BDCE@tobyinkster.co.uk> <925A648E-35D3-4224-98F3-FDB84ACB67B4@randomchaos.com> Message-ID: <48DED229.3050000@weborganics.co.uk> Hello Scott Scott Reynen wrote: > On [Sep 27], at [ Sep 27] 4:27 , Toby A Inkster wrote: > >>> If any style sheet language can be used, why don't microformats create >>> their own style language eg: >>> 4th Jan, 1968 >> >> By definition, the contents of the style attribute must be in "the >> default style sheet language". The default style sheet language is by >> definition CSS unless a Content-Style-Type header (either HTTP header >> or ) is present. There can only be one default style >> sheet language per document, thus any document which wants to use a >> non-CSS style sheet language in the style attribute cannot use CSS in >> the style attribute. (That is, you can't use CSS in some style >> attributes and non-CSS on others.) > > That's certainly a reason not to make this a recommendation for > everyone, but as we already have two alternative methods (machine data > as human data and abbr-design-pattern), I'm not convinced we should > discount this idea altogether. Conflict with CSS is only an issue > with inline CSS, which is widely regarded as a poor practice anyway, > especially among publishers paying enough attention to have concerns > about the abbr-design-pattern. And it may not even be an issue there, > as CSS says user agents "must ignore declarations with invalid > values." [1] Thank you Scott you are absolutely correct Best Wishes Martin McEvoy > > I'm afraid we may be dismissing this too hastily. My initial reaction > to this idea was to view it as semantic abuse of the style attribute, > but after thinking about it more, I now think it makes a lot of sense > that "1968-01-04" should be treated as styling instructions for "4th > Jan, 1968." We already have different kinds of styling instructions > in CSS (i.e. visual, aural, and physical). I'd argue that this is a > simply another type of instruction, context-dependent, just as much > explaining how the content should be presented, e.g. it should be > presented in whatever way ISO 8601 dates are presented in a given > context. There may be good reasons this won't work, but I don't think > the fact that no one has previously used @style for anything other > than CSS is one of them. After all, the same was widely true of > @class before we started promoting the alternative uses allowed under > the HTML spec. > > [1] http://www.w3.org/TR/CSS21/conform.html#conformance > > Peace, > Scott > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From mail at tobyinkster.co.uk Sun Sep 28 01:53:37 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Sep 28 01:54:08 2008 Subject: [uf-discuss] ISO Dates and Durations using Style Message-ID: <57F89752-3E7F-48B7-B34F-132C76F76909@tobyinkster.co.uk> Martin McEvoy wrote: > No Tantek and Toby you are misguided in your interpretation please > cite > your sources ... http://www.w3.org/TR/REC-html40/present/styles.html#h-14.2.2 "The syntax of the value of the style attribute is determined by the default style sheet language." http://www.w3.org/TR/REC-html40/present/styles.html#h-14.2.1 """User agents should determine the default style sheet language for a document according to the following steps (highest to lowest priority): 1. If any META declarations specify the "Content-Style-Type", the last one in the character stream determines the default style sheet language. 2. Otherwise, if any HTTP headers specify the "Content-Style-Type", the last one in the character stream determines the default style sheet language. 3. Otherwise, the default style sheet language is "text/css".""" HTTP headers and are document-wide in scope, which means that you can only change the default style sheet language on a document-wide basis. > this is a valid solution. It is certainly valid in an SGML sense. And it does conform to the HTML spec *if* you set the Content-Style-Type header. However, if you do so, then any use of CSS in style attributes becomes non-conformant. The ability to use CSS in style attributes being very handy, I don't think this is a very good solution. -- Toby A Inkster From martin at weborganics.co.uk Sun Sep 28 06:04:13 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Sep 28 06:04:21 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <57F89752-3E7F-48B7-B34F-132C76F76909@tobyinkster.co.uk> References: <57F89752-3E7F-48B7-B34F-132C76F76909@tobyinkster.co.uk> Message-ID: <48DF80CD.9040809@weborganics.co.uk> Hello Toby Toby A Inkster wrote: > Martin McEvoy wrote: > [...edit..] > >> this is a valid solution. > > It is certainly valid in an SGML sense. And it does conform to the > HTML spec *if* you set the Content-Style-Type header. However, if you > do so, then any use of CSS in style attributes becomes non-conformant. Sorry my example was a bad one I over simplified it... the question I am posing is should microformats use their own style-sheet language, vendor specific for microformats in order to tackle the abbr design pattern issue, vendor specific extensions should use this pattern, '-' + vendor identifier + '-' + meaningful name http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords which leads me to believe that publishers can do something like this... 4th Jan, 1968 CSS parsers will just ignore the above markup as vendor specific, of course It will not validate (because its not CSS), but I believe that this is a lesser evil than stuffing the values into @title, a machine wont choke on the data it will just ignore it, where as at the moment people do choke on the data because it makes little sense to them, its in the wrong place. > > The ability to use CSS in style attributes being very handy, I agree.. > I don't think this is a very good solution. > I dont think the current abbr-design-pattern is a very good solution either but what choices are there, I just want to fix it and not give anyone an excuse not to publish microformats. Best Wishes Martin McEvoy From bhawkeslewis at googlemail.com Sun Sep 28 07:05:16 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Sun Sep 28 07:05:24 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <48DF80CD.9040809@weborganics.co.uk> References: <57F89752-3E7F-48B7-B34F-132C76F76909@tobyinkster.co.uk> <48DF80CD.9040809@weborganics.co.uk> Message-ID: <48DF8F1C.5000300@googlemail.com> Martin McEvoy wrote: > '-' + vendor identifier + '-' + meaningful name > > http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords > > which leads me to believe that publishers can do something like this... > > 4th Jan, 1968 > > but I believe that > this is a lesser evil than stuffing the values into @title, a machine > wont choke on the data it will just ignore it, where as at the moment > people do choke on the data because it makes little sense to them, its > in the wrong place. 1. Sticking a hyphen at the beginning of the property name is not all there is to it. The CSS 2.1 specification only defines error-handling for (unrecognized) vendor-specific properties only work when their names and values can be parsed with the CSS core grammar. That might well be possible with "1968-01-04"; I haven't tried to evaluate it. Alternately, you might need to put it in a quoted string (like with the value of the "content" property). 2. Just because the parsing of vendor-specific properties that do match the grammar is defined does not make them conforming. I don't think requiring microformat users to produce non-conforming, invalid CSS is compatible with microformats' selling point of building "upon existing and widely adopted standards". I don't think there's _any_ fundamental difference in terms of conformance between sticking this data into a vendor-specific CSS property and into a HTML custom attribute, and the later would be a _lot_ less hacky. 3. The hidden data problem is very hard to solve in HTML 4.01 but I think we already have more conforming "hacks" than this (data in class name, empty span with title, object data, and hidden input among them). -- Benjamin Hawkes-Lewis From martin at weborganics.co.uk Sun Sep 28 08:58:52 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Sep 28 08:59:01 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <48DF8F1C.5000300@googlemail.com> References: <57F89752-3E7F-48B7-B34F-132C76F76909@tobyinkster.co.uk> <48DF80CD.9040809@weborganics.co.uk> <48DF8F1C.5000300@googlemail.com> Message-ID: <48DFA9BC.3090908@weborganics.co.uk> Hello Benjamin Benjamin Hawkes-Lewis wrote: > 1. Sticking a hyphen at the beginning of the property name is not all > there is to it. The CSS 2.1 specification only defines error-handling > for (unrecognized) vendor-specific properties only work when their > names and values can be parsed with the CSS core grammar. That might > well be possible with "1968-01-04"; I haven't tried to evaluate it. > Alternately, you might need to put it in a quoted string (like with > the value of the "content" property). I hadn't thought of that something like this maybe... 4th Jan, 1968 It doesn't produce any errors with the validator, but is it still a "hack" Best Wishes Martin McEvoy From bhawkeslewis at googlemail.com Sun Sep 28 09:35:40 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Sun Sep 28 09:35:49 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <48DFA9BC.3090908@weborganics.co.uk> References: <57F89752-3E7F-48B7-B34F-132C76F76909@tobyinkster.co.uk> <48DF80CD.9040809@weborganics.co.uk> <48DF8F1C.5000300@googlemail.com> <48DFA9BC.3090908@weborganics.co.uk> Message-ID: <48DFB25C.5040306@googlemail.com> Martin McEvoy wrote: > I hadn't thought of that something like this maybe... > > 4th Jan, 1968 > > It doesn't produce any errors with the validator, but is it still a "hack" Worse still, it would conflict with how the CSS3 Generated and Replaced Content Module Working Draft proposes browsers apply "content" to elements (namely, by replacing their actual content in the rendering): http://www.w3.org/TR/2003/WD-css3-content-20030514/#inserting3 -- Benjamin Hawkes-Lewis From martin at weborganics.co.uk Sun Sep 28 10:18:16 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Sep 28 10:18:24 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <48DFB25C.5040306@googlemail.com> References: <57F89752-3E7F-48B7-B34F-132C76F76909@tobyinkster.co.uk> <48DF80CD.9040809@weborganics.co.uk> <48DF8F1C.5000300@googlemail.com> <48DFA9BC.3090908@weborganics.co.uk> <48DFB25C.5040306@googlemail.com> Message-ID: <48DFBC58.2000704@weborganics.co.uk> Hello Benjamin Benjamin Hawkes-Lewis wrote: > Martin McEvoy wrote: >> I hadn't thought of that something like this maybe... >> >> 4th Jan, 1968 >> >> It doesn't produce any errors with the validator, but is it still a >> "hack" > > Worse still, it would conflict with how the CSS3 Generated and > Replaced Content Module Working Draft proposes browsers apply > "content" to elements (namely, by replacing their actual content in > the rendering): does this apply to in-line elements? I would guess it does, I tested the example in a CSS3 validator with again no errors, I don't know if this will cause any problems with browsers either as most seem to default to CSS2? Best wishes Martin McEvoy > > http://www.w3.org/TR/2003/WD-css3-content-20030514/#inserting3 > > -- > Benjamin Hawkes-Lewis > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From bhawkeslewis at googlemail.com Sun Sep 28 10:38:10 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Sun Sep 28 10:38:17 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <48DFBC58.2000704@weborganics.co.uk> References: <57F89752-3E7F-48B7-B34F-132C76F76909@tobyinkster.co.uk> <48DF80CD.9040809@weborganics.co.uk> <48DF8F1C.5000300@googlemail.com> <48DFA9BC.3090908@weborganics.co.uk> <48DFB25C.5040306@googlemail.com> <48DFBC58.2000704@weborganics.co.uk> Message-ID: <48DFC102.7010404@googlemail.com> Martin McEvoy wrote: > does this apply to in-line elements? By my reading of the proposals, yes (both in the sense of inline/text-level elements and elements styled "display: inline;"). > I would guess it does, I tested the > example in a CSS3 validator with again no errors, Why would you expect a validity error? Your proposed use of it is valid syntax but utterly incompatible with how it should work. > I don't know if this > will cause any problems with browsers either as most seem to default to > CSS2? It will cause problems if browser developers ever implement W3C's proposals. If your suggestion was widely implemented, it would make implementing W3C's proposals impossible. This is practically a case study of why only designated extension points (like class and meta and vendor-specific prefixes) should be used for extensions. I'm not sure what you mean by "default to CSS2". Popular browsers do not branch their CSS-handling code for different CSS levels; most implement a mixture of features from different levels, including CSS3 proposals. -- Benjamin Hawkes-Lewis From mail at tobyinkster.co.uk Sun Sep 28 10:42:06 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun Sep 28 10:42:41 2008 Subject: [uf-discuss] ISO Dates and Durations using Style Message-ID: Benjamin Hawkes-Lewis wrote: > It will cause problems if browser developers ever implement W3C's > proposals. Opera implemented support for CSS's "content" property on real elements (as against pseudo-elements) a very long time ago (Opera 5 or 6 IIRC) but dropped it later on. -- Toby A Inkster From bhawkeslewis at googlemail.com Sun Sep 28 11:00:53 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Sun Sep 28 11:01:00 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: References: Message-ID: <48DFC655.2050601@googlemail.com> Toby A Inkster wrote: > Opera implemented support for CSS's "content" property on real elements > (as against pseudo-elements) a very long time ago (Opera 5 or 6 IIRC) > but dropped it later on. Actually, "content" appears to be working with Opera 9.52 Mac and 4th Jan, 1968 right now. So I guess we can scrap the "if". The solution wouldn't work as desired even with today's browsers. -- Benjamin Hawkes-Lewis From martin at weborganics.co.uk Sun Sep 28 11:21:37 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Sep 28 11:21:45 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <48DFC655.2050601@googlemail.com> References: <48DFC655.2050601@googlemail.com> Message-ID: <48DFCB31.5050405@weborganics.co.uk> Benjamin Hawkes-Lewis wrote: > Toby A Inkster wrote: >> Opera implemented support for CSS's "content" property on real >> elements (as against pseudo-elements) a very long time ago (Opera 5 >> or 6 IIRC) but dropped it later on. > > Actually, "content" appears to be working with Opera 9.52 Mac and > 4th Jan, 1968 > right now. So I guess we can scrap the "if". The solution wouldn't > work as desired even with today's browsers. Oh! this is true, tested on IE8, FF3 Chrome nothing changed Tested on Opera9.5 content: does work.. OK thanks all for letting me bang my head against a wall again ;-) I give up! Best Wishes Martin McEvoy > > -- > Benjamin Hawkes-Lewis > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From martin at weborganics.co.uk Sun Sep 28 12:12:14 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Sep 28 12:12:23 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <48DFCB31.5050405@weborganics.co.uk> References: <48DFC655.2050601@googlemail.com> <48DFCB31.5050405@weborganics.co.uk> Message-ID: <48DFD70E.5000801@weborganics.co.uk> Martin McEvoy wrote: > Benjamin Hawkes-Lewis wrote: >> Toby A Inkster wrote: >>> Opera implemented support for CSS's "content" property on real >>> elements (as against pseudo-elements) a very long time ago (Opera 5 >>> or 6 IIRC) but dropped it later on. >> >> Actually, "content" appears to be working with Opera 9.52 Mac and >> 4th Jan, 1968 >> right now. So I guess we can scrap the "if". The solution wouldn't >> work as desired even with today's browsers. > Oh! this is true, tested on IE8, FF3 Chrome nothing changed > > Tested on Opera9.5 content: does work.. OK thanks all for letting me > bang my head against a wall again ;-) > I give up! One question what is actually wrong with using an extension eg: 4th Jan, 1968 apart from the CSS validation issues, which when you compare it with the current and @title accessibility issues doesn't seem so bad to me? Thanks Martin McEvoy > > Best Wishes > > Martin McEvoy >> >> -- >> Benjamin Hawkes-Lewis >> >> _______________________________________________ >> microformats-discuss mailing list >> microformats-discuss@microformats.org >> http://microformats.org/mailman/listinfo/microformats-discuss > From bhawkeslewis at googlemail.com Sun Sep 28 13:36:20 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Sun Sep 28 13:36:31 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <48DFD70E.5000801@weborganics.co.uk> References: <48DFC655.2050601@googlemail.com> <48DFCB31.5050405@weborganics.co.uk> <48DFD70E.5000801@weborganics.co.uk> Message-ID: <48DFEAC4.4000008@googlemail.com> Martin McEvoy wrote: > One question what is actually wrong with using an extension eg: > > 4th Jan, 1968 > > apart from the CSS validation issues, which when you compare it with the > current and @title accessibility issues doesn't seem so bad to me? The only direct accessibility issue I can think of is that if you had a tool that stripped out styling information before presentation to a user who needed to apply their own formatting, the data would be stripped along with the presentational suggestions. There are a couple more indirect considerations: 1. Encouraging non-conforming code could produce more mistakes; without a quality control process, mistakes are less likely to be noticed when they only affect users with certain disabilities. 2. It would constitute a barrier of adoption to publishers aiming to produce webpages that conform to accessibility guidelines that require conforming or even just valid CSS and reduce the benefits of such microformats reaching users with disabilities via sites designed to be usable for them. For example, a page using this syntax probably could not pass WCAG 1.0 Checkpoint 3.2 ("Create documents that validate to published formal grammars.") and therefore could not pass at the Priority 2 level. These issues are by no means as significant as the accessibility problems with abbr and title. But in terms of what is wrong with it more generally, this solution is every bit as non-conforming (though not quite as risky) as an HTML custom attribute, with the additional ugliness of putting required data into a layer intended for optional presentational suggestions. Given that HTML custom attributes are a non-starter for microformats because they build on existing standards, I can't see how this proposal is going to gain any traction. -- Benjamin Hawkes-Lewis From martin at weborganics.co.uk Sun Sep 28 17:19:43 2008 From: martin at weborganics.co.uk (Martin McEvoy) Date: Sun Sep 28 17:19:52 2008 Subject: [uf-discuss] ISO Dates and Durations using Style In-Reply-To: <48DFEAC4.4000008@googlemail.com> References: <48DFC655.2050601@googlemail.com> <48DFCB31.5050405@weborganics.co.uk> <48DFD70E.5000801@weborganics.co.uk> <48DFEAC4.4000008@googlemail.com> Message-ID: <48E01F1F.1070904@weborganics.co.uk> Benjamin Hawkes-Lewis wrote: > Martin McEvoy wrote: > >> One question what is actually wrong with using an extension eg: >> >> 4th Jan, >> 1968 >> >> apart from the CSS validation issues, which when you compare it with >> the current and @title accessibility issues doesn't seem so >> bad to me? > > The only direct accessibility issue I can think of is that if you had > a tool that stripped out styling information before presentation to a > user who needed to apply their own formatting, the data would be > stripped along with the presentational suggestions. agreed.... > > There are a couple more indirect considerations: > > 1. Encouraging non-conforming code could produce more mistakes; > without a quality control process, mistakes are less likely to be > noticed when they only affect users with certain disabilities. yes this too.... > > 2. It would constitute a barrier of adoption to publishers aiming to > produce webpages that conform to accessibility guidelines that require > conforming or even just valid CSS and reduce the benefits of such > microformats reaching users with disabilities via sites designed to be > usable for them. For example, a page using this syntax probably could > not pass WCAG 1.0 Checkpoint 3.2 ("Create documents that validate to > published formal grammars.") and therefore could not pass at the > Priority 2 level. Nicely said thank you very informative absolutely correct also. > > These issues are by no means as significant as the accessibility > problems with abbr and title. the lesser of the two evils so to speak.. :-) > > But in terms of what is wrong with it more generally, this solution is > every bit as non-conforming (though not quite as risky) as an HTML > custom attribute, with the additional ugliness of putting required > data into a layer intended for optional presentational suggestions. even if they are just presentational suggestions for a parser? because this is practically what the abbr pattern does using @title? where would I put that data then? if I were copying popular usage patterns that data would be in the head in a meta tag referenced in some meaningful way (how I don't know), but instead it seems (to me) that I have to take that data and place it in the content hidden in @title a cool trick! I guess that's why microformats are referred to quite often now as "hacky". This is just my though so don't jump up and down, I am known to think a little out of the box, microformats can overcome their issues if they just accept one thing machine data belongs in the head of a document, not in the content were it currently is. > Given that HTML custom attributes are a non-starter for microformats > because they build on existing standards, I can't see how this > proposal is going to gain any traction. It wasn't really a proposal of any kind I am just cycling through the many options. > > -- > Benjamin Hawkes-Lewis > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From mail at tobyinkster.co.uk Tue Sep 30 02:17:37 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Tue Sep 30 02:18:06 2008 Subject: [uf-discuss] ISO Dates and Durations using Style Message-ID: <20E8DEFB-9CB5-4F87-9D90-CD4A7C0CBB7D@tobyinkster.co.uk> One problem with this idea is the difficulty of parsing. (I know that as per microformats principles, the needs of implementors come third, after the needs of users and the needs of publishers - but the needs of implementors do still need to be taken into account!) It would mean that all microformats tools would have to include a full CSS- parsing ability. Otherwise they might pick up false positives from things like: #event1 .dtstart { -uf-content: '2008-01-01' } Then you end up with parsers needing to follow all rel=stylesheet links, @import rules, etc. -- Toby A Inkster