Re: [uf-discuss] Currency microformat
Hello, (Hopefully this will get to the mailing... haven't been able to get through in a while. But we'll see) I'm actually working on a globalization of currencies project right now. (And have dealt with this issue in the past too.) For us, each user of the system has a specified locale. (Like: en_US, fr_CA, etc.) And with that locale, there is a default currency associated with that. In our system there's a PHP function that takes care of printing money. All it really does is add the proper currency symbol and puts it in the correct place (for the local). Although, internally, in the database, currencies info is stored in ISO 4217 format. First guess would be to use the abbr design pattenn for this -- http://microformats.org/wiki/abbr-design-pattern Maybe something like... Pay me abbr class=currency title=CAD$/abbr5.00 now! Although something like the the following might be better... Pay me span class=moneyabbr class=currency title=CAD$/abbr5.00/span now! But it might be more semantic salt than is considered necessary. Just having the abbr with the class-currency near a number might be good enough. But that's open for discussion though. Thoughts? Some other things to consider... there might be an implicit currency that comes with what's defined in the HTML lang attribute. Like if you have lang=fr-CA than you could assume the currency is CAD. (But that takes some intelligence to do that kind of mapping.) (Also, I know this is bad. But I don't think we are consistently using the lang attribute in our system.) Also, this is all just my experience. It would be useful to see what others are doing too. See ya On 7/17/06, Ben Buchanan [EMAIL PROTECTED] wrote: Hi all, A recent discussion with a travelling friend has sparked some ideas about a microformat for displaying prices and other currency-based figures. The classic problem example would be a page stating a price of $50. Is that Australian dollars? US dollars? Monopoly money? :) So anyway I'm following The Process (http://microformats.org/wiki/process) and I'm up to searching for existing formats/work. So far I've only seen the ISO standard for three-letter codes, no format or microformat for consistently displaying them. Does anyone know of relevant resources I should check out? cheers, Ben -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Make Televisionhttp://maketelevision.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Resolving Microformats List Problem
Hello, I think I know what's causing the Microformats mailing list problem. I think e-mails are being silently rejected when they are sent in HTML format. (Even if that e-mail has a text alternate too.) See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Make Televisionhttp://maketelevision.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] comments microformat
Hi! on this page: http://microformats.org/wiki/comment-problem The problem with comments is posed in terms of monitoring/tracking. Isn't that already too specific? I would have written down the problem in terms of parsing: how can I recognize that this or that bit of code is a comment. Seems to me comment tracking is a subset of what could be done with comments. Not sure where to write this on the wiki, etc. And of course, I'd like to get involved in this comments microformats (I work for coComment). I think I've already brought this up (on IRC if not here) but it's not quite clear what needs to be done now. Collecting comment markup is one thing I remember -- is that a relevant thing to do now? It seems to answer the question what does a comment look like more than how do I track comments -- another thing that makes me say the problem isn't spellt out correctly. Thoughts? Thanks Steph aka bunny -- http://climbtothestars.org/ http://cocomment.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat
On 7/18/06, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Maybe something like... Pay me abbr class=currency title=CAD$/abbr5.00 now! Something along these lines would be pretty sensible IMO Some other things to consider... there might be an implicit currency that comes with what's defined in the HTML lang attribute. Like if you have lang=fr-CA than you could assume the currency is CAD. (But that takes some intelligence to do that kind of mapping.) I'm very wary of this - a website in France might want to provide an English translation for international customers, but shouldn't have to then convert all the costs into GBP, for instance. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] comments microformat
Hello, I may be the only one doing this, but I tend to use rel-comment, rev-comment, and rel-comments. Here's an example of rev-comment... http://changelog.ca/log/2006/07/09/goodbye_phonebook And here's an example of rel-comment... http://changelog.ca/log/2005/08/21/rss-disposition-hinting-proposal I also make use of rel-comments too. (Note the s at the end.) Here's an example... http://maketelevision.com/ See ya On 7/18/06, Stephanie Booth (bunny) [EMAIL PROTECTED] wrote: Hi! on this page: http://microformats.org/wiki/comment-problem The problem with comments is posed in terms of monitoring/tracking. Isn't that already too specific? I would have written down the problem in terms of parsing: how can I recognize that this or that bit of code is a comment. Seems to me comment tracking is a subset of what could be done with comments. Not sure where to write this on the wiki, etc. And of course, I'd like to get involved in this comments microformats (I work for coComment). I think I've already brought this up (on IRC if not here) but it's not quite clear what needs to be done now. Collecting comment markup is one thing I remember -- is that a relevant thing to do now? It seems to answer the question what does a comment look like more than how do I track comments -- another thing that makes me say the problem isn't spellt out correctly. Thoughts? Thanks Steph aka bunny -- http://climbtothestars.org/ http://cocomment.com/ -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Make Televisionhttp://maketelevision.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat
On Tue, 18 Jul 2006 11:12:11 +0200, Ben Ward [EMAIL PROTECTED] wrote: On 18 Jul 2006, at 07:24, Ben Buchanan wrote: The classic problem example would be a page stating a price of $50. Is that Australian dollars? US dollars? Monopoly money? :) This is certainly a worthy cause, but to play devil's advocate for a moment, could pure HTML be sufficient? html lang=en-gb pMy new T-Shirts cost £30, but it cost my friend in Canada span lang=en-ca$34/span/p /html Language does not indicate currency, and any such use would be abuse. I may write something like: p lang=nbDen kanadiske prisen på t-skjorten var 34 $/p (The Canadian price of the t-shirt was $34) I am still very much writing in Norwegian (Bokmål), using a Norwegian convention of postfixing the currency symbol instead of prefixing it, but I am refering to the Canadian Dollar. I would probably suggest marking this up using classnames: p lang=nbDen kanadiske prisen på t-skjorten var span class=currency CAD34 $/span./p You could of course also complicate this further by using inline elements to separate value from symbol. -- Arve Bersvendsen, Opera Software ASA, http://www.opera.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat
Arve Bersvendsen [EMAIL PROTECTED] writes: p lang=nbDen kanadiske prisen på t-skjorten var span class=currency CAD34 $/span./p I like this idea. The earlier abbr/ based one was good too. You could of course also complicate this further by using inline elements to separate value from symbol. There's no need IMHO. A constraint that money must be represented in number systems with alphanumeric characters would seem to be acceptable to delineate the scalar value from the symbol. -- Nic Ferrier http://www.tapsellferrier.co.uk for all your tapsell ferrier needs ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat
I may be totally out in left field because I haven't really studied up on the wiki as much as I should have but wouldn't something like this make more sense in terms of a currency microformat: span class=moneyabbr class=currency title=CAD eng$/ abbrspan class=amount5.00/span/span In this format the wrapping would be money or something similar followed by either the actual amount or the currency, depending on what rules your country/language follows in regards to the order. Since there can be a difference between different languages within countries I thought it might be a good idea to include that in the currency definition of the formating, eg., CAD eng or CAD fr. It could also give sites that list multiple languages a way to differentiate when they show multiple prices. So far on the examples sent to the list there has been no definition around the actual dollar amount which confused me a bit. I'm curious, is there a reason for that? Feel free to let me know if I'm missing the point completely as I am new to the world of microformats. Cheers, Mike Stickel On Jul 18, 2006, at 1:34 AM, Charles Iliya Krempeaux wrote: Hello, Here's a handy list of ISO 4217 codes... http://www.xe.com/iso4217.htm Also, here's an example of the $ being used in (Canadian) French... https://secure.vmp.com/signup/adv_signup.php?locale=fr_CA Note the placement of the dollar sign AFTER the number. The same page in (USA) English can be seen here... https://secure.vmp.com/signup/adv_signup.php?locale=en_US (Just some example for the examples in the wild.) See ya On 7/18/06, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello, (Hopefully this will get to the mailing... haven't been able to get through in a while. But we'll see) I'm actually working on a globalization of currencies project right now. (And have dealt with this issue in the past too.) For us, each user of the system has a specified locale. (Like: en_US, fr_CA, etc.) And with that locale, there is a default currency associated with that. In our system there's a PHP function that takes care of printing money. All it really does is add the proper currency symbol and puts it in the correct place (for the local). Although, internally, in the database, currencies info is stored in ISO 4217 format. First guess would be to use the abbr design pattenn for this -- http://microformats.org/wiki/abbr-design-pattern Maybe something like... Pay me abbr class=currency title=CAD$/abbr5.00 now! Although something like the the following might be better... Pay me span class=moneyabbr class=currency title=CAD$/abbr5.00/span now! But it might be more semantic salt than is considered necessary. Just having the abbr with the class-currency near a number might be good enough. But that's open for discussion though. Thoughts? Some other things to consider... there might be an implicit currency that comes with what's defined in the HTML lang attribute. Like if you have lang=fr-CA than you could assume the currency is CAD. (But that takes some intelligence to do that kind of mapping.) (Also, I know this is bad. But I don't think we are consistently using the lang attribute in our system.) Also, this is all just my experience. It would be useful to see what others are doing too. See ya On 7/17/06, Ben Buchanan [EMAIL PROTECTED] wrote: Hi all, A recent discussion with a travelling friend has sparked some ideas about a microformat for displaying prices and other currency-based figures. The classic problem example would be a page stating a price of $50. Is that Australian dollars? US dollars? Monopoly money? :) So anyway I'm following The Process (http://microformats.org/wiki/process) and I'm up to searching for existing formats/work. So far I've only seen the ISO standard for three-letter codes, no format or microformat for consistently displaying them. Does anyone know of relevant resources I should check out? cheers, Ben Charles Iliya Krempeaux, B.Sc. Mike Stickel Screenflicker Developments | GoNecksGo | ChanceCube http://screenflicker.com | http://gonecksgo.com | http://chancecube.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat
On 7/18/06, Mike Stickel [EMAIL PROTECTED] wrote: Since there can be a difference between different languages within countries I thought it might be a good idea to include that in the currency definition of the formating, eg., CAD eng or CAD fr. If you need to specify the language, for instance to indicate how to interpret the chars/spacing in the number formatting, HTML has the @lang attribute which covers this (@lang=fr_CA and @lang=en_CA in this case). However, there's been a lot of close coupling of the concepts of 'language' and 'currency' in this discussion so far and I don't think that's at all necessary - I should be able to go to a foreign website that provides an English translation without my user-agent assuming the prices are in US Dollars, for example. So far on the examples sent to the list there has been no definition around the actual dollar amount which confused me a bit. I'm curious, is there a reason for that? The only microformat that I've noticed currency units in is hListing, and that deliberately shies away from parsing the actual values because it's too free-form in most existing Listing formats. My own preference would be for something like: p class=moneyThis item costs span class=currencyGBP/span span class=amount10.00/span /p Which with similar parsing rules to existing formats would also allow things like: p class=money It'll cost you abbr class=currency title=50.00fifty/abbr abbr class=amount title=GBPquid/abbr , mate! /p Or, a more complex example with multiple languages: p lang=en span class=money span class=amount50/span abbr class=currency title=GBPpound;/abbr /span span lang=fr class=money (c'est span class=amount75/span abbr class=currency title=EUReuro;/abbr pour ca) /span /p (sorry about the bad french) It'd be pretty neat to have a browser widget that converted all the USD prices on an American site into their equivalent GBP on mouseover, or something along those lines. -C ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat
On 7/18/06, Ciaran McNulty [EMAIL PROTECTED] wrote: Or, a more complex example with multiple languages: [...] Sorry, screwed this up a bit. I meant to demonstrate different number formatting. p lang=en Price: span class=money abbr class=currency title=GBPpound;/abbr span class=amount1,250.00/span /span span lang=fr class=money (Prix: span class=amount1600,00/span abbr class=currency title=EUReuro;/abbr ) /span /p ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat
On Jul 18, 2006, at 9:54 AM, Ciaran McNulty wrote: It'd be pretty neat to have a browser widget that converted all the USD prices on an American site into their equivalent GBP on mouseover, or something along those lines. It already is pretty neat: http://viewmycurrency.wordpress.com/about/ In addition to that FireFox extension, here are two Greasemonkey scripts that manage to do currency conversion with no microformats: http://nybblelabs.org.uk/projects/exchequer http://6v8.gamboni.org/Greasemonkey-Yahoo-Finance.html Which prompts the question: what exactly is the problem we're trying to solve here? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat
On 7/18/06, Scott Reynen [EMAIL PROTECTED] wrote: It already is pretty neat: http://viewmycurrency.wordpress.com/about/ http://nybblelabs.org.uk/projects/exchequer http://6v8.gamboni.org/Greasemonkey-Yahoo-Finance.html Which prompts the question: what exactly is the problem we're trying to solve here? Huh, good point. Wonder how it works? -Ciaran ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat, or numbers with units
On 7/18/06 8:10 AM, Scott Reynen [EMAIL PROTECTED] wrote: On Jul 18, 2006, at 9:54 AM, Ciaran McNulty wrote: It'd be pretty neat to have a browser widget that converted all the USD prices on an American site into their equivalent GBP on mouseover, or something along those lines. It already is pretty neat: http://viewmycurrency.wordpress.com/about/ In addition to that FireFox extension, here are two Greasemonkey scripts that manage to do currency conversion with no microformats: http://nybblelabs.org.uk/projects/exchequer http://6v8.gamboni.org/Greasemonkey-Yahoo-Finance.html Which prompts the question: what exactly is the problem we're trying to solve here? Excellent question Scott. Certainly if the (presumed) problem has already been solved, especially with something as open as a Greasemonkey script, it's not clear that there is a strong enough need to justify a microformat. Many years ago when I was working on XHTML 2.0 (yes, I am actually one of the contributors to that spec, despite my opinions of it), one of the new proposals I put forth was an element to indicate a numerical value with a unit. I think you can see where I am going with this. Currency is a reasonable easy problem to solve as indicated by the scripts. Amounts in arbitrary units is a bit harder and necessary for several applications. For example, consider the work that has been done on a recipe microformat. http://microformats.org/wiki/recipe-examples Though we haven't reached this problem yet in the research, I can see it coming: Say you wanted to create a shopping list application which you could tell which recipes you wanted to cook, and have it automatically total up all the various amounts of ingredients and give you the net amount of stuff you wanted to pick up. It would need to be able to determine precise amounts/units of each ingredient. This might turn out to be like the currency problem, or it might be more complex, given the variety of units used in recipes, English vs. metric etc. That's a case that might need a microformat. We need more research and analysis to really justify it, but I can see it within the realm of probable possibility. Food for thought. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Developing a strategy for deployment of microformats
Hi Ryan Sorry for the delay in replying to this. -Original Message- From: Ryan King [mailto:[EMAIL PROTECTED] Sent: 05 July 2006 22:36 To: [EMAIL PROTECTED]; Microformats Discuss Subject: Re: [uf-discuss] Developing a strategy for deployment of microformats On Jul 3, 2006, at 7:26 AM, Brian Kelly wrote: However I've encountered a number of irritating problems: Problems with British Summer Time (Daylight Saving Time). What problems, specifically? Times being an hour out. Not a hCalendar problem, I understand, but ba complexiyty of processing times. However I had expected that software would have realised that BST was in operation - I understand that I have to use the UTC time +1.00.00.00. Another problem - going to, for example, http://www.bath.ac.uk/whats-on/getevent.php?event_id=3010catIds=ALL Tails use the correct date (17 July) whereas the Google hCalendar Greeasemonkey script uses a date of 16 July. I've been told that this is a well-known problem in handling date and time information, and is not directly related to microformats or the software which processes microformats. However it strikes me that we will need to ensure that end users (and microformat maintainers) are aware of such limitations. It also strikes me that there's a need for consistency across the software vendors - which then leads on to (a) more rigorous documentation regarding what should be done and (b) test cases. Is anyone working on this? Yes. hCalendar test cases are in progress at http://hg.microformats.org/tests . Is this the correct URL - it seems to be a change log rather than a page described the test cases. ... As well as the issues regarding the spec and the hCard converters there are also the issues about limitations in the calendaring tools. I've read some messages about Outlook, for example, not processing telephone numbers in hCards correctly. In this case, I think there's a need for documentation on bugs in well-used software such as Outlook. We have some already: http://microformats.org/wiki/vcard-implementations http://microformats.org/wiki/icalendar-implementations Thanks - it is aimed at programmers ... Feel free to add more. but I appreciate that I (and others) can help to give it more user-focussed content. There is also a need to define what hCard tools should do if they encounter multiple occurrences of hCards. I understand that Brian Suda's Web- based XSLT service processes the first occurrence on a page, No, it processes all of them. If I use the bookmarklet on the http://www.ukoln.ac.uk/web-focus/events/workshops/webmaster-2006/sessions/ke lly/ I get one hCard, whereas Tails correctly displays two. whereas Tails displays all occurrences in a sidebar. Should the spec mandate what the software should do in such circumstances? No. Each application has different constraints. OK. In which case ideally the application will document the constrainst (to avoid users thinking that one ap[plication determines what the effect should be). Thanks agin. Brian -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat
In message [EMAIL PROTECTED], Ben Buchanan [EMAIL PROTECTED] writes The classic problem example would be a page stating a price of $50. Is that Australian dollars? US dollars? Monopoly money? :) It seems to me that the issues with currency (whether or not microformats are involved) are, or at least include: Conveying the currency of the amount. Consider: span class=currency-GBP5.99/span [where currency-GBP could be styled in such a way that the pound-sterling symbol is prepended (or appended, according to the applicable language), in the same way that q tags don't require separate quote marks - how would this degrade on non-CSS browsers, though?] This could equally be achieved by a new (X)HTML tag: currency type=GBP5.99/currency or some other mechanism; I'll use that hypothetical tag from now on, for illustrative purposes. Consider a defunct currency; one old UK Shilling (written 1/ or 1/-, they hyphen representing zero pennies; equivalent of a modern GBP 0.05): currency type=GBP unit=shilling1/currency and: currency type=GBP unit=old-penny6/currency or: currency type=GBP equivalence=0.051//currency and: currency type=GBP equivalence=0.025-/6/currency Indeed, we may wish to enable our user-agents to interpret an amount of money in modern parlance: currency type=GBP unit=shilling date=18901/currency Might be interpreted as: 1/- (worth pound;4.50 [1] in modern terms) There would be further complications where the entire currency has disappeared, (such as French Francs into Euros) rather than just the fractions of the main unit (as old English shillings/ pennies, into new pence): currency type=FFR equivalence=EUR0/1.5210/currency [1] or whatever -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat
In message [EMAIL PROTECTED], Charles Iliya Krempeaux [EMAIL PROTECTED] writes Maybe something like... Pay me abbr class=currency title=CAD$/abbr5.00 now! Although something like the the following might be better... Pay me span class=moneyabbr class=currency title=CAD$/abbr5.00/span now! To me, the latter is better, because the number is included in the markup, not merely the symbol. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Resolving Microformats List Problem
On Jul 18, 2006, at 12:24 AM, Charles Iliya Krempeaux wrote: Hello, I think I know what's causing the Microformats mailing list problem. I think e-mails are being silently rejected when they are sent in HTML format. (Even if that e-mail has a text alternate too.) /me has light bulb moment I just remembered that I'd set the lists to strip/reject html email, intending to just test it, but forgot to set it back. I didn't expect rejections to be silent. I added text/html back to the accepted list and changed the behavior to 'reject', rather than 'discard'. Sorry for the trouble, -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Developing a strategy for deployment of microformats
On Jul 18, 2006, at 9:12 AM, Brian Kelly wrote: Hi Ryan Sorry for the delay in replying to this. -Original Message- From: Ryan King [mailto:[EMAIL PROTECTED] Sent: 05 July 2006 22:36 To: [EMAIL PROTECTED]; Microformats Discuss Subject: Re: [uf-discuss] Developing a strategy for deployment of microformats On Jul 3, 2006, at 7:26 AM, Brian Kelly wrote: However I've encountered a number of irritating problems: Problems with British Summer Time (Daylight Saving Time). What problems, specifically? Times being an hour out. Not a hCalendar problem, I understand, but ba complexiyty of processing times. However I had expected that software would have realised that BST was in operation - I understand that I have to use the UTC time +1.00.00.00. I'm not sure how BST can be assumed here? Another problem - going to, for example, http://www.bath.ac.uk/whats-on/getevent.php?event_id=3010catIds=ALL Tails use the correct date (17 July) whereas the Google hCalendar Greeasemonkey script uses a date of 16 July. I'm not familiar that greasemonkey script. You may want to talk to its author. I've been told that this is a well-known problem in handling date and time information, and is not directly related to microformats or the software which processes microformats. However it strikes me that we will need to ensure that end users (and microformat maintainers) are aware of such limitations. It also strikes me that there's a need for consistency across the software vendors - which then leads on to (a) more rigorous documentation regarding what should be done and (b) test cases. Is anyone working on this? Yes. hCalendar test cases are in progress at http://hg.microformats.org/tests . Is this the correct URL - it seems to be a change log rather than a page described the test cases. Its a Mercurial repository. Hence the 'in progress' qualifier The stable tests are published at http://microformats.org/tests/ .Of course, that doesn't really have any explanatory material, either. ... I think there's a need for documentation on bugs in well-used software such as Outlook. We have some already: http://microformats.org/wiki/vcard-implementations http://microformats.org/wiki/icalendar-implementations Thanks - it is aimed at programmers ... Well, that's what we are. :D ... There is also a need to define what hCard tools should do if they encounter multiple occurrences of hCards. I understand that Brian Suda's Web- based XSLT service processes the first occurrence on a page, No, it processes all of them. If I use the bookmarklet on the http://www.ukoln.ac.uk/web-focus/events/workshops/webmaster-2006/ sessions/kelly/ I get one hCard, whereas Tails correctly displays two. I can't currently access that URL. I'll try again later. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Developing a strategy for deployment of microformats
On Jul 18, 2006, at 2:03 PM, Ryan King wrote: Another problem - going to, for example, http://www.bath.ac.uk/whats-on/getevent.php?event_id=3010catIds=ALL Tails use the correct date (17 July) whereas the Google hCalendar Greeasemonkey script uses a date of 16 July. I'm not familiar that greasemonkey script. You may want to talk to its author. I know of two such scripts, and I am the author of one. I'm not currently able to load that URL, so I can't see the problem right now. There are three places where this can go wrong: 1) in the markup, 2) in the Greasemonkey script, and 3) at Google Calendar. For 1), in my limited testing, almost no one is publishing time zones correctly, which is only an obvious problem when you try to use an event across time zones. For 2), if there is a bug, I'll need to see the URL in question to track it down. For 3), I vaguely recall Google Calendar doesn't always correctly convert times to the time zone set in your preferences. Most problems are in 1) and/or 3), which makes it difficult to track down problems in 2). Garbage in, garbage out, as they say. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Developing a strategy for deployment of microformats
There is another gotcha with date-times in iCalendar. This might not be your issue and i'm not sure how various implementations handle this, but end dates are not inclusive. For example: DTSTART: 20060101 DTEND: 20060102 This is NOT a two day event, this will end at midnight between the 1st and 2nd. If you wanted a two day event you would have to use DTSTART: 20060101 DTEND: 20060103 -or- DTSTART: 20060101 DTEND: 20060102T235959 Google Calendar MIGHT be using INCLUSIVE dates (it would be a simple test to find out), so that might be some of the problems as well. Just an FYI to anyone, be aware of this, i know i have been guilty myself of coding-up an hCalendar and then forgetting about exclusive dates and having conference events ending a day short! -brian Scott Reynen wrote: On Jul 18, 2006, at 2:03 PM, Ryan King wrote: Another problem - going to, for example, http://www.bath.ac.uk/whats-on/getevent.php?event_id=3010catIds=ALL Tails use the correct date (17 July) whereas the Google hCalendar Greeasemonkey script uses a date of 16 July. I'm not familiar that greasemonkey script. You may want to talk to its author. I know of two such scripts, and I am the author of one. I'm not currently able to load that URL, so I can't see the problem right now. There are three places where this can go wrong: 1) in the markup, 2) in the Greasemonkey script, and 3) at Google Calendar. For 1), in my limited testing, almost no one is publishing time zones correctly, which is only an obvious problem when you try to use an event across time zones. For 2), if there is a bug, I'll need to see the URL in question to track it down. For 3), I vaguely recall Google Calendar doesn't always correctly convert times to the time zone set in your preferences. Most problems are in 1) and/or 3), which makes it difficult to track down problems in 2). Garbage in, garbage out, as they say. Peace, Scott ___ 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
[uf-discuss] creators updated
The javascript creators have been updated, please let me know if you see any problems. http://microformats.org/code/hcard/creator http://microformats.org/code/hcalendar/creator http://microformats.org/code/hreview/creator -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] creators updated
Hi Ryan, I've noticed couple of small issues: 1. hCard Creator: AIM screenname YIM screenname overlap each other in Safari 2. hCalendar Creator: dtend has fromat 2006620, I think should be 20060620 3. hReview Creator: word date* in review date* jumps on the next row and moves reviewer* down in Safari. It looks like review is label for date, date* is label for text field and reviewer* is label for empty row. Also I didn't noticed value of url field in generated code. And also, should photo be inside an item as well as fn and url? Cheers, Dmitry P.S. Do you need russian localization of these pages. I already done one for XFN creator, but I don't know where to post it. On 19/07/2006, at 8:57 AM, Ryan King wrote: The javascript creators have been updated, please let me know if you see any problems. http://microformats.org/code/hcard/creator http://microformats.org/code/hcalendar/creator http://microformats.org/code/hreview/creator -ryan -- Ryan King [EMAIL PROTECTED] ___ 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
