>> [A-Za-z0-9] effectively only covers English. There are hundreds of languages and thousands of characters covered by Unicode.
I concur, but your statement does not make my suggestion invalid. I was suggested (said a different way) a default that doesn't require the additional complexity of always having to define the currency symbol, letting it instead be assumed (i.e. if symbol is not specificed then assume that any non [A-Za-z0-9] characters comprise currency symbols), and if it is required then include the symbol. Complexity of implementation will be the bane of adoption; I'm pushing to reduce complexity. This after being someone the prior 20 years always advocated to approach perfection which increased complexity. I'm learning some valuable lessons from other's Web 2.0 successes. >> I don't see it as overlapping, but rather leaving room for future expansion. Okay. >> What? I have no idea what you're talking about, I think you misunderstood what I was saying. By abbreviations, I was referring to abbreviated class names, like those used in hCard. I may have misunderstood. I thought you were saying it would be possible to support *both* a long name and an abbreviation. If I misunderstood, sorry for my missing the point. -Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt Sent: Saturday, October 14, 2006 6:41 AM To: Microformats Discuss Subject: Re: [uf-discuss] Currency Quickpoll: Preliminary results Mike Schinkel wrote: > Lachlan Hunt wrote: >> 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? No, that's my point. Have you seen how many characters there are in Unicode? It may be theoretically possible to write such a regular expression, but it would very complex. > 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? [A-Za-z0-9] effectively only covers English. There are hundreds of languages and thousands of characters covered by Unicode. >> 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? Yes. > OTOH, if there is another microformat planned for measure, is it > advisable to design in overlap? I don't see it as overlapping, but rather leaving room for future expansion. >> One of the problems I have with hCard is that those abbreviated class >> names are difficult to comprehend and remember... >> >> 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. What? I have no idea what you're talking about, I think you misunderstood what I was saying. By abbreviations, I was referring to abbreviated class names, like those used in hCard. -- 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