RE: [uf-discuss] First version of Currency proposal
span class=currency title=USD$1,000/span In the US that will mean one dollar, in Argentina (where I'm from) it will mean a thousand dollars. I believe you misunderstood what I was proposing; a shorthand for cases where it was unambiguous. When it was ambiguous it would require more. Unless I misunderstand, you would almost never use three decimal places for money and if you did you'd need to use the unambiguous version. Right? I do agree though that there should be some sort of optimization. It's becoming clearer and clearer to me that this is essential. Question: How does a human currently interpret a website that is have values such as $1,000 when it it was designed by a US company with US customers in mind? Is there something in the HTTP headers that makes this explicit that a machine could read, or does the Argentine viewing the web page just have to figure it out in context? If not, then we'd need a page-global currency seperator too... -Mike P.S. I apologize on behalf of myself and my countrymen for us being so USA-centric, but we unfortunately are. Hopefully globalization will open our eyes and change that before much longer. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emiliano Martinez Luque Sent: Friday, October 20, 2006 12:29 AM To: Microformats Discuss Subject: Re: [uf-discuss] First version of Currency proposal This gives me a chance to ask in a different way, why can we not assume type=USD, amount=5.99, and symbol=$ from the following? The book costs span class=currency title=USD$5.99/span That example in particular might not be a problem but consider the following: span class=currency title=USD$1,000/span In the US that will mean one dollar, in Argentina (where I'm from) it will mean a thousand dollars. And tying this to the currency identification (even though the first 2 letters represent a country) will not solve the issue, since I should be able to markup values in different currencies within a single web page. I do agree though that there should be some sort of optimization. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
On 10/20/06, Emiliano Martinez Luque [EMAIL PROTECTED] wrote: That example in particular might not be a problem but consider the following: span class=currency title=USD$1,000/span In the US that will mean one dollar, in Argentina (where I'm from) it will mean a thousand dollars. And tying this to the currency identification (even though the first 2 letters represent a country) will not solve the issue, since I should be able to markup values in different currencies within a single web page. I do agree though that there should be some sort of optimization. Actually it's 1000 in America too ;-) There are plenty of other countries where your assertion is true, though. However I'm not convinced that the problem of number-parsing needs to be solved in a microformat. The @lang attribute already exists in HTML and should indicate which locale numeric values are being written in. This would then hopefully also cover more complex cases like figures written in Japanese etc. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
On 10/20/06, Mike Schinkel [EMAIL PROTECTED] wrote: Question: How does a human currently interpret a website that is have values such as $1,000 when it it was designed by a US company with US customers in mind? Is there something in the HTTP headers that makes this explicit that a machine could read, or does the Argentine viewing the web page just have to figure it out in context? If not, then we'd need a page-global currency seperator too... The @lang attribute specifies an ISO639[1] or ISO3166[2] country code for the element it's applied to (and any descendant elements. The W3C recommend[3] that the HTML element have this for every page. You could easily, for instance have: html lang=en-gb [...] pThis product is $1,000 (span lang=fr-pr1.500€/span)/p [...] /html And hopefully a user agent would know how to parse the numbers. @lang also has benefits for things like screen readers and so on. -Ciaran McNulty [1] http://ftp.ics.uci.edu/pub/ietf/http/related/iso639.txt [2] http://ftp.ics.uci.edu/pub/ietf/http/related/iso3166.txt [3] http://www.w3.org/International/O-HTML-tags.html ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] First version of Currency proposal
Cool, thanks. html lang=en-gb Question: how would someone implement a wiki with different pages in different languages since they don't have access to changing the header or HTML element for each wiki page? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ciaran McNulty Sent: Friday, October 20, 2006 4:34 AM To: Microformats Discuss Subject: Re: [uf-discuss] First version of Currency proposal On 10/20/06, Mike Schinkel [EMAIL PROTECTED] wrote: Question: How does a human currently interpret a website that is have values such as $1,000 when it it was designed by a US company with US customers in mind? Is there something in the HTTP headers that makes this explicit that a machine could read, or does the Argentine viewing the web page just have to figure it out in context? If not, then we'd need a page-global currency seperator too... The @lang attribute specifies an ISO639[1] or ISO3166[2] country code for the element it's applied to (and any descendant elements. The W3C recommend[3] that the HTML element have this for every page. You could easily, for instance have: html lang=en-gb [...] pThis product is $1,000 (span lang=fr-pr1.500€/span)/p [...] /html And hopefully a user agent would know how to parse the numbers. @lang also has benefits for things like screen readers and so on. -Ciaran McNulty [1] http://ftp.ics.uci.edu/pub/ietf/http/related/iso639.txt [2] http://ftp.ics.uci.edu/pub/ietf/http/related/iso3166.txt [3] http://www.w3.org/International/O-HTML-tags.html ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
On 10/20/06, Mike Schinkel [EMAIL PROTECTED] wrote: Question: how would someone implement a wiki with different pages in different languages since they don't have access to changing the header or HTML element for each wiki page? I'm not that familiar with Wikis, they could probably implement a per-page language setting. The @lang doesn't have to be on the HTML element really. As long as it's on *an* element that contains your content, a user-agent should know what's going on. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] First version of Currency proposal
I'm not that familiar with Wikis, they could probably implement a per-page language setting. The problem is not whether they can or cannot, but whether they will or won't and whether the user (who won't be the developer in almost all cases) will have the skill and/or motivation to make the change. Same is true of Content management systems (CMS) and Forums. See here for how many Wikis and CMS and Forums would need to get updated: http://www.wikimatrix.org/ http://www.cmsmatrix.org/ http://www.forummatrix.org/ I see it like how Microformats fundamental constraint is to not have to change HTML so we can use them *now*. I believe we've got to go with what people can actually use today given the tools they are currently using w/o fundamental change. The @lang doesn't have to be on the HTML element really. As long as it's on *an* element that contains your content, a user-agent should know what's going on. If that's true, then that works! An author could enclose everything they type into a wiki page, CMS page, or forum post using a div like so: DIV @lang=en-us The rain in Spain stays mainly in the plain. /DIV -Mike P.S. BTW, the issues with conent on Wikis and CMS and Forums is why this proposal concerns me: http://gmpg.org/xmdp/ I have been planning to ask about it as soon as I had a chance to study it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ciaran McNulty Sent: Friday, October 20, 2006 5:14 AM To: Microformats Discuss Subject: Re: [uf-discuss] First version of Currency proposal On 10/20/06, Mike Schinkel [EMAIL PROTECTED] wrote: Question: how would someone implement a wiki with different pages in different languages since they don't have access to changing the header or HTML element for each wiki page? I'm not that familiar with Wikis, they could probably implement a per-page language setting. The @lang doesn't have to be on the HTML element really. As long as it's on *an* element that contains your content, a user-agent should know what's going on. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
This gives me a chance to ask in a different way, why can we not assume type=USD, amount=5.99, and symbol=$ from the following? The book costs span class=currency title=USD$5.99/span That example in particular might not be a problem but consider the following: span class=currency title=USD$1,000/span In the US that will mean one dollar, in Argentina (where I'm from) it will mean a thousand dollars. And tying this to the currency identification (even though the first 2 letters represent a country) will not solve the issue, since I should be able to markup values in different currencies within a single web page. I do agree though that there should be some sort of optimization. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
In message [EMAIL PROTECTED], Emiliano Martinez Luque [EMAIL PROTECTED] writes Regarding the Straw man proposal, the symbol class seems to be unnecesary since the symbol in most price representations is just a convention to define which currency we are speaking of. Not so. Suppose there is a page with the markup (simplified): The book costs $span class=USD5.99/span and I have a user agent (a Firefox extension, say) which replaces the dollar value with the value in pounds sterling. I'd get: The book costs $£3.50 which is clearly nonsense. By wrapping the dollar sign in a span (or whatever) with the class symbol, the user agent is made aware of its presence, and can hide it when inserting the sterling value. Likewise for the unit in 50 span class-unitcents/span -- 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] First version of Currency proposal
The book costs $span class=USD5.99/span This gives me a chance to ask in a different way, why can we not assume type=USD, amount=5.99, and symbol=$ from the following? The book costs span class=currency title=USD$5.99/span I believe you answer will be what about unicode where we are not using [A-Za-z0-9] and if so, I would say that is when you add a symbol. In my example, symbol is the non-[A-Za-z0-9] character(s) *if* no symbol is explicitly specified. Can you give me an example where that would not work? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Saturday, October 14, 2006 6:53 AM To: Microformats Discuss Subject: Re: [uf-discuss] First version of Currency proposal In message [EMAIL PROTECTED], Emiliano Martinez Luque [EMAIL PROTECTED] writes Regarding the Straw man proposal, the symbol class seems to be unnecesary since the symbol in most price representations is just a convention to define which currency we are speaking of. Not so. Suppose there is a page with the markup (simplified): The book costs $span class=USD5.99/span and I have a user agent (a Firefox extension, say) which replaces the dollar value with the value in pounds sterling. I'd get: The book costs $£3.50 which is clearly nonsense. By wrapping the dollar sign in a span (or whatever) with the class symbol, the user agent is made aware of its presence, and can hide it when inserting the sterling value. Likewise for the unit in 50 span class-unitcents/span -- 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] First version of Currency proposal
I believe you answer will be what about unicode where we are not using [A-Za-z0-9] and if so, I would say that is when you add a symbol. In my example, symbol is the non-[A-Za-z0-9] character(s) *if* no symbol is explicitly specified. Can you give me an example where that would not work? yy span class=currency title=USD$zz 5.99/span Where yy and zz are, say Japanese or Urdu characters (where zz might mean, again for example, approximately). I'm sorry, I made a mistake in my question. I didn't mean to say is non [digits+periods+commas] (I don't know how to write the regex at the moment.). So in your example, clearly it would require specifying the symbol. But when only digits and seperators? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Saturday, October 14, 2006 4:04 PM To: Microformats Discuss Subject: Re: [uf-discuss] First version of Currency proposal In message [EMAIL PROTECTED], Mike Schinkel [EMAIL PROTECTED] writes This gives me a chance to ask in a different way, why can we not assume type=USD, amount=5.99, and symbol=$ from the following? The book costs span class=currency title=USD$5.99/span I believe you answer will be what about unicode where we are not using [A-Za-z0-9] and if so, I would say that is when you add a symbol. In my example, symbol is the non-[A-Za-z0-9] character(s) *if* no symbol is explicitly specified. Can you give me an example where that would not work? yy span class=currency title=USD$zz 5.99/span Where yy and zz are, say Japanese or Urdu characters (where zz might mean, again for example, approximately). -- 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
Le 06-10-12 à 23:18, Scott Reynen a écrit : span class=moneyabbr class=amount title=0./abbrabbr class=currency title=USD¢/abbr/span This is the sort of absurdity that the credit card advertisers engage in. I'm not sure what this means. Do you not think 99¢ means fundamentally the same thing as 0.99USD? What you see is 99 and what you get is less than 1. That's only true if you consider the value outside the context of the currency, and I don't know why anyone would do that. 99 is a meaningless monetary value without a currency assigned. If the currency is going to be optional, I think it at least needs to be implied. Otherwise we just have a number with no idea what it means. And if there's an established currency, then why not use the unit already explicitly defined by that currency's ISO 4217 code? Why throw away the D in USD? http://en.wikipedia.org/wiki/ISO_4217 The first two letters of the code are the two letters of ISO 3166-1 alpha-2 country codes There are also issues in the way you divide numbers. In many countries, number are organized by sequence of 3 digits. For example, in Japan 10 yen = ju(10) yen 1000 yen = ichi(1) sen yen but1 yen = ichi(1) man yen (and not ju sen yen) 1 万 man 1000 千 sen wa-on kan-onmandarin 1 一 hito ichi yi 2 二 futa ni ar, liang * 3 三 mi san san 4 四 yonshi *si 5 五 itsutsugo wu 6 六 mu roku liu 7 七 nana shichi * qi 8 八 ya hachiba 9 九 kokonotsu kyuu jiu 10 十 toujyuu shi And this is actually used in daily life, in case people think its a corner case. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
On Oct 13, 2006, at 1:55 AM, Karl Dubost wrote: There are also issues in the way you divide numbers. In many countries, number are organized by sequence of 3 digits. For example, in Japan 10 yen = ju(10) yen 1000 yen = ichi(1) sen yen but1 yen = ichi(1) man yen (and not ju sen yen) 1 万 man 1000 千 sen And this is actually used in daily life, in case people think its a corner case. Good point. Can we get some examples of Japanese currency publishing in the wiki? I'd lean towards making this machine-readable without listing every unit for every currency, e.g.: abbr class=amount title=1000一千/abbrabbr class=currency title=JPY¥/abbr Otherwise, we face the task of defining currency units, and that's likely to be a huge headache for us and I think actually more work for publishers to track down the appropriate unit symbol. Consider also: The car costs $20k. I sold my old baseball cards for five benjamins. The war has cost $500 billion so far. These will require either special pre-defined units for k, benjamins, and billion or use of abbr to provide a machine- readable equivalent in a standard (dollar) unit. I think the latter is much simpler. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
Scott, I am sorry, but your example is a very good reductio ad absurdum argument against what you are advocating. At 11:51 PM 2006-10-11, Scott Reynen wrote: On Oct 11, 2006, at 6:33 PM, Guillaume Lebleu wrote: Scott Reynen wrote: So which of these tasks should we aim to make simple? I'd say the latter, because it's far more common (well over 80%, I think). I think we agree here. $99 is more common than 99c, so the former should be simpler to microformat than the latter. Where it seems we differ in opinion is that the latter should still be possible to microformat. I don't think disagree there at all, and I'm not sure where you got that impression. To paraphrase you, what is simpler? to give a solution, although a bit less simple, to the minority of people who uses 99c, or to ask them to change the way they do things and use $0.99? I believe in the former. I'll repeat my example here, because it doesn't require altering the published content at all: span class=moneyabbr class=amount title=0./abbrabbr class=currency title=USD¢/abbr/span This is the sort of absurdity that the credit card advertisers engage in. What you see is 99 and what you get is less than 1. Don't go there. Maintain the functional integrity of the construction, or you will generate lots of errors through uncomprehending use. That would be displayed as: 99¢, just like your examples. It doesn't prevent anyone from using the microformat. It just requires them to provide a machine-readable equivalent in the standard dollar unit, just like we provide machine-readable date equivalents in the standard ISO 8601 format, despite published date formats varying widely. I think you'll agree that the following is pretty simple: span class=moneyabbr class=currency title=USD$/ abbrspan class=amount99/span/span And most people in this community seems to be in agreement with this. I haven't seen anyone disagree with this. Now, what do we offer to people who use amounts in U.S. cents on their Web site. Have them provide dollar equivalents in abbr titles, while maintaining the exact same published content. Nothing or something? No one is suggesting nothing, so I'm not sure why you're discussing that option here. If we want to offer something, then for 70 US cents as in http:// www.smh.com.au/articles/2004/07/01/1088488063161.html? from=storylhs, we could have: span class=moneyspan class=amount70/span abbr class=currency title=USDUS/abbr abbr class=unit title=centcents/abbr/span We could, but what are the advantages of this over the example above? The advantage is transparency: what you see is what you get. The semantic construction of the value you are talking about is. amount -- subcategory: currency -- measure: US cent == US$ / 100 -- count == 70 in other words, text\amount\currency\numberOf(US$/100 a.k.a. cent):70 You should be able to validate the relationship between what you see and what you get (if they are stated differently) from (possibly a chain of) mutually understood (by business and by consumer) relationships, such as divided by 100. Not just define them separately and independently. This gives both the consumer and the business the ability to detect and purge errors. Al My 2 cents My 0.02 dollars. 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
Re: [uf-discuss] First version of Currency proposal
I'll repeat my example here, because it doesn't require altering the published content at all: span class=moneyabbr class=amount title=0./abbrabbr class=currency title=USD¢/abbr/span This is the sort of absurdity that the credit card advertisers engage in. What you see is 99 and what you get is less than 1. Don't go there. Maintain the functional integrity of the construction, or you will generate lots of errors through uncomprehending use. Actually, his example makes perfect sense. 99¢ == 0.99$ and since USD == $ therefore the client app will either end up reading 0.99 out of the data (as in his example) or converting 99¢ to 0.99 so that it can work with it... which amounts to the same thing, the second is just more code. There is no absurdity present. In fact, to force code to convert centrs to dollars when dollars could have easily been encoded in the original format seems almost absurd. Although either works. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
On Oct 12, 2006, at 7:35 AM, Al Gilman wrote: span class=moneyabbr class=amount title=0./abbrabbr class=currency title=USD¢/abbr/span This is the sort of absurdity that the credit card advertisers engage in. I'm not sure what this means. Do you not think 99¢ means fundamentally the same thing as 0.99USD? What you see is 99 and what you get is less than 1. That's only true if you consider the value outside the context of the currency, and I don't know why anyone would do that. 99 is a meaningless monetary value without a currency assigned. If the currency is going to be optional, I think it at least needs to be implied. Otherwise we just have a number with no idea what it means. And if there's an established currency, then why not use the unit already explicitly defined by that currency's ISO 4217 code? Why throw away the D in USD? Don't go there. Maintain the functional integrity of the construction, or you will generate lots of errors through uncomprehending use. In my above example, the publisher only needs to understand the relationship between dollars and cents (just like I need to understand the relationship between January 1, 2000 and 2000-01-01). In the example with an additional units property, the publisher only needs to know the standard symbol for their unit of choice (e.g. cent). I think the former knowledge is much more common than the latter. We don't even know the latter ourselves. If we're going to allow various units within any given currency, how would publishers (and parsers) know which units are commonly accepted, and what are the common symbols for identifying those units? Are we going to create our own list of every possible currency unit? If there isn't an existing standard here, that might be a good indication that there isn't a need for a standard here, because conversion to the default unit is a common and trivial practice. How many currencies are we even talking about here anyway? Looking at the ISO 4217 list, it seems to me most of these currencies (maybe 80%?) only have one unit to choose, which suggests to me that allowing for communication in other units is an unnecessary complication. Are there really enough multi-unit currencies that it's worth trying to standardize the non-default units? Peace, Scott___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
Scott Reynen wrote: span class=moneyabbr class=amount title=0./abbrabbr class=currency title=USD¢/abbr/span My bad. I had missed the title=0.99 part earlier. This will work for all currency amounts of recent times, as all currencies are now officially or de facto decimalized (UK was one of the last ones in 1971, see http://en.wikipedia.org/wiki/Decimalization), and indeed saves us from talking about units for now. Thank you, Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
King Chung Huang wrote: Is currency unit intended to be one whole name or two names? My intention is to have 2 class names, one for the currency (ex. U.S. currency), and one for the unit within that currency (ex. Dollar, Cent). unit is optional, b/c most currencies have a default unit (Dollar in the case of the U.S. currency). I have added more details to the proposal on this. See: http://microformats.org/wiki/currency-proposal Hope this helps. Thank you for your feedback, Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
On Oct 11, 2006, at 1:18 PM, Guillaume Lebleu wrote: My intention is to have 2 class names, one for the currency (ex. U.S. currency), and one for the unit within that currency (ex. Dollar, Cent). unit is optional, b/c most currencies have a default unit (Dollar in the case of the U.S. currency). I have added more details to the proposal on this. See: http:// microformats.org/wiki/currency-proposal I'm not sure the example of this really works: span class=moneyspan class=amount99/spanabbr class=unit¢ /abbrabbr class=currency title=USD/abbr/span Specifically, I don't think it makes sense to have the first abbr tag with no title, and the second abbr with no content. It looks like you're trying to communicate three different pieces of information when only two are really being published. Can we just treat everything as the default unit and adjust the machine-readable values accordingly? E.g.: span class=moneyabbr class=amount title=0./abbrabbr class=currency title=USD¢/abbr/span Is there a currency example in which this wouldn't work? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
Scott Reynen wrote: Specifically, I don't think it makes sense to have the first abbr tag with no title, and the second abbr with no content. It looks like you're trying to communicate three different pieces of information when only two are really being published. Thank you for the feedback. Let me first clear up what I am trying to communicate here. My rationale is that in 99 cents, the two pieces of information published are the amount and the unit of currency (See http://en.wikipedia.org/wiki/Cent_(currency)), not the amount and the currency. Without context, the currency piece of information in 99 cents could be U.S. currency, Australian currency, Canadian currency or Euro currency. This is what I am trying to reflect. See also: http://www.austlii.edu.au/au/legis/cth/consol_act/ca1965120/s8.html that clearly shows the distinction between the currency and the denomination. The reason why there is no title attribute in abbr class=unit¢/abbr in my example is b/c I don't want to get ahead of myself and leave this up to the measure proposal, but it should be abbr class=unit title=[some standard/agreed upon code for cent] Can we just treat everything as the default unit Not sure what you mean in the context of the 99c example. The default unit for the US currency is the Dollar, not the Cent, but in the context of the 99c context, we need to ensure that Dollar is not picked as the unit, but Cent instead is. and adjust the machine-readable values accordingly? E.g.: span class=moneyabbr class=amount title=0./abbrabbr class=currency title=USD¢/abbr/span So using this notation would require the parser to interpret the ¢ as the cent unit of the USD currency without this information being disambiguated using a microformat. It would certainly work, assuming you can deal with the different way of representing the Cent information, but isn't our goal here to make interpretation easier, and not require to have to deal with all these tiny differences? Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
On Oct 11, 2006, at 2:43 PM, Guillaume Lebleu wrote: Can we just treat everything as the default unit Not sure what you mean in the context of the 99c example. The default unit for the US currency is the Dollar, not the Cent, but in the context of the 99c context, we need to ensure that Dollar is not picked as the unit, but Cent instead is. What I'm suggesting is that everything be treated as dollars in USD and everything be treated as Yen in JPY. Isn't that how most applications and people deal with money anyway? If you want to consider your money as cents in your own publishing or your own application, you can make the simple conversion (multiply or divide by 100) necessary to use the microformat's assumed unit of dollar. Is there any currency with multiple units that aren't simple and constant fractions of a standard unit? and adjust the machine-readable values accordingly? E.g.: span class=moneyabbr class=amount title=0./ abbrabbr class=currency title=USD¢/abbr/span So using this notation would require the parser to interpret the ¢ as the cent unit of the USD currency without this information being disambiguated using a microformat. It seems like you're making this more complicated than it needs to be. The amount is 0.99. That's an amount in the dollar unit, which would be assumed for all USD currency. There is no cent unit here, and no requirement to interpret a cent unit. When you say 99¢, do you mean anything that isn't a direct equivalent of $0.99? Why should a parser care what symbols you use to convey that meaning? If everyone uses the same unit, communication will be much easier, and I'm not seeing any reason everyone can't do easily use the same unit for machines. It seems most publishers (well over 80%) already use the same unit for people, and the edge cases can convert for machines using abbr just like we all convert to a standard date format for machines. It would certainly work, assuming you can deal with the different way of representing the Cent information Doesn't the word cent literally mean one perCENT of a dollar? I'm not seeing the benefit of treating cent as a distinct unit. but isn't our goal here to make interpretation easier, and not require to have to deal with all these tiny differences? Yes, and I'd say the concept of a cent is a tiny difference that parsers shouldn't have to deal with when the concept of a dollar works just fine to communicate the exact same information. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes Please find it at: http://microformats.org/wiki/currency-proposal How does this relate to the proposal in: http://microformats.org/wiki/currency-brainstorming#Straw_man_proposal It doesn't even seem to link to the page on which the latter sits, and seems to disregard a number of other issues raised on that page and in mailing list discussion. -- 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] First version of Currency proposal
Scott Reynen wrote: What I'm suggesting is that everything be treated as dollars in USD and everything be treated as Yen in JPY. Isn't that how most applications and people deal with money anyway? I think this will indeed work in most cases. There are some examples on the Web that make use of cents, and my design philosophy with this proposal was to make simple things simple to microformat, and complex things possible to microformat, without requiring publishers to change some of their practices: - http://www.99only.com/ - http://www.smh.com.au/articles/2004/07/01/1088488063161.html?from=storylhs But we certainly could, if this is the consensus of this community, to enforce that all microformatted money amounts be expressed in the default unit of each currency. What I have seen in other standardization processes, is the documentation of the different options explored with benefits/drawbacks for each, to allow easy side-by-side comparison by the community. I think this will be my next step. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
On Oct 11, 2006, at 4:13 PM, Guillaume Lebleu wrote: There are some examples on the Web that make use of cents, and my design philosophy with this proposal was to make simple things simple to microformat, and complex things possible to microformat, without requiring publishers to change some of their practices While a nice design philosophy in general, I don't think make simple things simple means very much outside the context of what exactly is being made simple. What qualifies as simple depends on what you're trying to accomplish. If you're trying to publish monetary values as cents, converting those values to dollars to make them machine readable is less simple than telling the machine that they're cents (assuming there is a standard way to indicate cents, which we don't currently seem to have). But if you're trying to publish monetary values as dollars, stating that your unit is dollars is less simple than assuming that's the case (or interpreting as much from the D in USD). So which of these tasks should we aim to make simple? I'd say the latter, because it's far more common (well over 80%, I think). Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
Scott Reynen wrote: So which of these tasks should we aim to make simple? I'd say the latter, because it's far more common (well over 80%, I think). I think we agree here. $99 is more common than 99c, so the former should be simpler to microformat than the latter. Where it seems we differ in opinion is that the latter should still be possible to microformat. To paraphrase you, what is simpler? to give a solution, although a bit less simple, to the minority of people who uses 99c, or to ask them to change the way they do things and use $0.99? I believe in the former. I think you'll agree that the following is pretty simple: span class=moneyabbr class=currency title=USD$/abbrspan class=amount99/span/span And most people in this community seems to be in agreement with this. See currency-brainstorming Now, what do we offer to people who use amounts in U.S. cents on their Web site. Nothing or something? If the community agrees it is a rarity, then we may want to just offer nothing (hopefull the poll I sent will provide useful feedback to this question). Users will come up with something themselves if the community was wrong. I have seen at least one web page where the cents part of the price was marking up (even when represented like $39.99) to display the .99 as superscript - I'll try to find this again and document it in examples. If we want to offer something, then for 70 US cents as in http://www.smh.com.au/articles/2004/07/01/1088488063161.html?from=storylhs, we could have: span class=moneyspan class=amount70/span abbr class=currency title=USDUS/abbr abbr class=unit title=centcents/abbr/span This is slightly more complex, but after all, people using this are relatively few. Now, what about 70 cents. I suggested using an empty abbreviation that was not well received, but an include link to a hidden global definition would work as well: abbr id=#u1 class=hidden currency title=USD$/abbr span class=moneyspan class=amount70/span abbr class=unit title=centcents/abbr a href=#u1 class=include/a/span That's a bit more complex, but at least there is something for the minority to follow. And my experience with standards is that if there is something that the community defined, and it works for a user's particular problem, then the user tends to go with it. My 2 cents, Guillaume Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss --No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.13.1/466 - Release Date: 10/7/2006 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
Scott Reynen wrote: On Oct 11, 2006, at 2:43 PM, Guillaume Lebleu wrote: Can we just treat everything as the default unit Not sure what you mean in the context of the 99c example. The default unit for the US currency is the Dollar, not the Cent, but in the context of the 99c context, we need to ensure that Dollar is not picked as the unit, but Cent instead is. What I'm suggesting is that everything be treated as dollars in USD and everything be treated as Yen in JPY. Isn't that how most applications and people deal with money anyway? No, not everyone. See, for example, Fuel Watch [1] which list all the prices in cents per litre. For them, changing it to dollars would probably be a little confusing because fuel prices are given everywhere in the country as cents per litre. [1] http://fuelwatch.com.au/ -- Lachlan Hunt http://lachy.id.au/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
Hi, I have just finnished reading both proposals, and here are some of my thoughts. Regarding the Straw man proposal, the symbol class seems to be unnecesary since the symbol in most price representations is just a convention to define which currency we are speaking of. So there is no actual need to explicitly mark it up as such, since User agents can (quite simply) derive it from the ISO code in any transformations that they might need to do. This is so, regardless of whether the symbol is present or not in the actual text. ie: span class=currency title=USD $abbr class=amount title=100.99100 and 99 cents/abbr /div Can be interpreted the same way by the User Agent as: span class=currency title=USDabbr class=amount title=100.99100.99/abbr/div The same thing can be said of the unit class in both proposals. Guillaume's example from his last mail: span class=moneyspan class=amount70/span abbr class=currency title=USDUS/abbr abbr class=unit title=centcents/abbr/span Can be Marked up, quite consistently as: span class=moneyspan class=amount title=0.7070/span abbr class=currency title=USDUS/abbr cents/span Since 0.70 USD is 70 cents. Remember that there might be text within a microformat that is to be discarded by a User Agent. An example of this from the hCard specification: span class=telspan class=typeHome/span (span class=typepref/spanerred): span class=value+1.415.555.1212/span /span The erred): text outside the type proprety is to be discarded by the User Agent. One thing I notice is that both in the Straw man proposal and in Gillaume's one, there is still the problem of how amounts are differently expressed across different countries. ie: 1,000.99 or 1.000,99 to represent a thousand and 99 cents of the currency. Has any thought been given of linking this to the language definition of the document (similar to the way that OSs handle locale)?. Ie: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en-US lang=en-US On Sale now for: span class=currency title=EUR $abbr class=amount100.99/abbr /div !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=es-AR lang=es-AR Oferta: span class=currency title=EUR US$abbr class=amount100,99/abbr /div Should both be understood as 100.99 EUR. And If some markup falls outside the scope of the locale it can be explicitelly marked up with the amount class. What do you think of this idea? Does any other solution has been proposed for this problem? Emiliano Martínez Luque ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
Guillaume Lebleu wrote: Please find it at: http://microformats.org/wiki/currency-proposal For tables of currency, I don't like the global definition method suggested. Tables cells have the scope and headers attributes available, so we should use them where possible. See, for example, this table of exchange rates, where each column represents one currency. http://au.finance.yahoo.com/currency The top row of headers could be marked up like this (ignoring the links they also use for simplicity): th scope=colabbr class=currency title=USDUS$/abbr/th Then every cell in that column can now automatically be a unit given in USD, and there is no need for the extra complexity of the include pattern. (It could also be implemented using the headers attribute on each cell, referencing the th using its ID.) For referencing a unit defined elsewhere in the document, so that you don't have to give it for every occurrence (especially where it's not within a table like that above), the WHATWG is defining the Web Apps spec a nice feature using dfn and abbr. e.g. This is the defining instance of the unit: span class=money dfnabbr class=currency unit title=AUD$/abbr/dfn39.00 /span And this is a cross reference to that in the same document: span class=moneyabbr$/abbr42.00/span http://www.whatwg.org/specs/web-apps/current-work/#the-dfn http://www.whatwg.org/specs/web-apps/current-work/#the-abbr Finally, I don't think the span class=amount is necessary at all. The spec can just define that everything within span class=money, excluding the currency and unit values, is the amount. We need to be careful not to add too many spans and classes everywhere, because it only makes the microformat harder to use. -- Lachlan Hunt http://lachy.id.au/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
I've just realized that the markup in my examples is wrong.. since I'm using title to define a value on the span element where I should be using the abbr element. I'm sorry about that, I was thinking more along the lines on how to parse the format than the actual mark up. Emiliano Martínez Luque ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
My message with corrected markup. Please disregard the other one. Regarding the Straw man proposal, the symbol class seems to be unnecesary since the symbol in most price representations is just a convention to define which currency we are speaking of. So there is no actual need to explicitly mark it up as such, since User agents can (quite simply) derive it from the ISO code in any transformations that they might need to do. This is so, regardless of whether the symbol is present or not in the actual text. ie: span class=money abbr class=currency symbol value=USD$/abbrabbr class=amount title=100.99100 and 99 cents/abbr /div Can be interpreted the same way by the User Agent as: span class=money abbr class=currency value=USD$/abbrabbr class=amount title=100.99100 and 99 cents/abbr /div Since the currency symbol can be derived from the ISO Currency code. The same thing can be said of the unit class in both proposals. Guillaume's example from his last mail: span class=moneyspan class=amount70/span abbr class=currency title=USDUS/abbr abbr class=unit title=centcents/abbr/span Can be Marked up, quite consistently as: span class=moneyabbr class=amount title=0.7070/abbr abbr class=currency title=USDUS/abbr cents/span Since 0.70 USD is 70 cents. Remember that there might be text within a microformat that is to be discarded by a User Agent. An example of this from the hCard specification: span class=telspan class=typeHome/span (span class=typepref/spanerred): span class=value+1.415.555.1212/span /span The erred): text outside the type proprety is to be discarded by the User Agent. One thing I notice is that both in the Straw man proposal and in Gillaume's one, there is still the problem of how amounts are differently expressed across different countries. ie: 1,000.99 or 1.000,99 to represent a thousand and 99 cents of the currency. Has any thought been given of linking this to the language definition of the document (similar to the way that OSs handle locale)?. Ie: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en-US lang=en-US On Sale now for: span class=money abbr class=currency title=EUR€/abbrabbr class=amount100.99/abbr /span !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=es-AR lang=es-AR Oferta: span class=money abbr class=currency title=EUR€/abbrabbr class=amount100,99/abbr /span Should both be understood as 100.99 EUR. And If some markup falls outside the scope of the locale it can be explicitelly marked up with the amount class. What do you think of this idea? Does any other solution has been proposed for this problem? Emiliano Martínez Luque PS: Sorry about the other mail. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
On Oct 11, 2006, at 6:33 PM, Guillaume Lebleu wrote: Scott Reynen wrote: So which of these tasks should we aim to make simple? I'd say the latter, because it's far more common (well over 80%, I think). I think we agree here. $99 is more common than 99c, so the former should be simpler to microformat than the latter. Where it seems we differ in opinion is that the latter should still be possible to microformat. I don't think disagree there at all, and I'm not sure where you got that impression. To paraphrase you, what is simpler? to give a solution, although a bit less simple, to the minority of people who uses 99c, or to ask them to change the way they do things and use $0.99? I believe in the former. I'll repeat my example here, because it doesn't require altering the published content at all: span class=moneyabbr class=amount title=0./abbrabbr class=currency title=USD¢/abbr/span That would be displayed as: 99¢, just like your examples. It doesn't prevent anyone from using the microformat. It just requires them to provide a machine-readable equivalent in the standard dollar unit, just like we provide machine-readable date equivalents in the standard ISO 8601 format, despite published date formats varying widely. I think you'll agree that the following is pretty simple: span class=moneyabbr class=currency title=USD$/ abbrspan class=amount99/span/span And most people in this community seems to be in agreement with this. I haven't seen anyone disagree with this. Now, what do we offer to people who use amounts in U.S. cents on their Web site. Have them provide dollar equivalents in abbr titles, while maintaining the exact same published content. Nothing or something? No one is suggesting nothing, so I'm not sure why you're discussing that option here. If we want to offer something, then for 70 US cents as in http:// www.smh.com.au/articles/2004/07/01/1088488063161.html? from=storylhs, we could have: span class=moneyspan class=amount70/span abbr class=currency title=USDUS/abbr abbr class=unit title=centcents/abbr/span We could, but what are the advantages of this over the example above? My 2 cents My 0.02 dollars. Peace, Scott___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] First version of Currency proposal
Please find it at: http://microformats.org/wiki/currency-proposal Thank you in advance for your feedback. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] First version of Currency proposal
Hi Guillaume, Is currency unit intended to be one whole name or two names? I believe specifying something with a class attribute value currency unit means it's of class currency and unit, not currency unit as a whole. Maybe currency-unit or currencyunit would be better? Cheers, King Chung Huang www.mobovivo.com On 10-Oct-06, at 10:53 PM, Guillaume Lebleu wrote: Please find it at: http://microformats.org/wiki/currency-proposal Thank you in advance for your feedback. Guillaume ___ 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
