>> It's not just about identifying which symbol represents the currency, but >> also which currency that symbol represents.
That's handled in my example. >> For a program to do so, it would have to be aware of every single >> alphanumeric character in Unicode. That does not just include [A-Za-z0-9]. >> It might be easier to do the reverse and know of every character that isn't >> a known currency symbol, but then even that list of symbols is missing some. Is there not a regular expression that can provide every single alphanumeric character? Alternately, wouldn't it be preferred to have minimal markup if [A-Za-z0-9] can be assumed and more complex markup if it cannot as opposed to having all cases be the more complex markup? >> However, the format could make provisions for some form of quantity, even if >> it doesn't explicitly define what such quantities are. I assume you are suggesting it would be optional, not required? OTOH, if there is another microformat planned for measure, is it advisable to design in overlap? >> One of the problems I have with hCard is that those abbreviated class names >> are difficult to comprehend and remember. In programming I generally prefer long well described names, but I called the question in case there would be people not implementing it just because they wanted to avoid bloat. I am not suggesting that I know that this is an issue, just posing the question. >> Abbreviations can be good in many cases, but you have to be careful not to >> introduce too much confusion or ambiguity for authors. However, I would disagree with abbreviations; the more ways it can be done, the more complexity in the spec and in the parser. Better to have just one way until desired functionality requires multiple ways. -Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt Sent: Friday, October 13, 2006 4:19 AM To: Microformats Discuss Subject: Re: [uf-discuss] Currency Quickpoll: Preliminary results Mike Schinkel wrote: > Thanks for the clarification. > > Further questions (and forgive me if I missed any of this before I joined): > >>> Currency symbol identification > > This is a naïve question: Doesn't the ISO 4217 code *imply* a symbol? > It appears so here: http://www.xe.com/symbols.htm Doesn't including > this in the microformat create redundancy? It's not just about identifying which symbol represents the currency, but also which currency that symbol represents. > Alternately, can't the symbols be extracted as not being alphanumeric > characters? For a program to do so, it would have to be aware of every single alphanumeric character in Unicode. That does not just include [A-Za-z0-9]. It might be easier to do the reverse and know of every character that isn't a known currency symbol, but then even that list of symbols is missing some. e.g. * U+FE69 ﹩ (Small Dollar Sign) * U+FF04 ＄ (Fullwidth Dollar Sign) * U+FFE5 ￥ (Fullwidth Yen Sign) * etc. It's much easier for the author to explicitly state which character(s) represent the symbol, than implementing heuristics to guess. > Broader Question: > Isn't the idea behind Microformats to be as consise, cohesive, and > single purposed as possible? If so, wouldn't that argue for > "combination with units (ex. $34 per gallon, $2 per miles)" being out > of scope and begging the need for a microformat that allows unit designation, > i.e. hUnits? Yes. Tackling the problem of identifying specific units under the currency format is far too complicated when you consider the sheer number of units there are, including SI units, Imperial units and US customary units, used for various quantities including number of units, length, mass, time, volume, area, energy, etc. However, the format could make provisions for some form of quantity, even if it doesn't explicitly define what such quantities are. e.g. price per Litre: <span class="money"> <abbr class="currency unit" title="AUD">$</abbr>1.23 <span class="quantity">L</span> </span> Or for each unit: <span class="money"> <abbr class="unit">$</abbr>4.95 <span class="quantity">each</span> </span> That way, if and when a microformat for units of measurement is introduced, that could easily be expanded to the following. e.g. <span class="quantity si-unit">L</span> > My last thought on the subject, is why are we using full names for > currency and amount instead of "cur" and "amt" to minimize bloat when > hCard uses names like "fn?" One of the problems I have with hCard is that those abbreviated class names are difficult to comprehend and remember. e.g. It's easy to get confused about what 'fn' means, since it could easily stand for family name, though it doesn't. (I'm not exactly sure what it stands for, though I assume it means "formatted name" even though it's not explicitly stated as such in the vCard RFC) Abbreviations can be good in many cases, but you have to be careful not to introduce too much confusion or ambiguity for authors. -- Lachlan Hunt http://lachy.id.au/ _______________________________________________ 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
