[uf-discuss] Currency Quickpoll: Preliminary results

Mike Schinkel mikeschinkel at gmail.com
Sat Oct 14 12:37:08 PDT 2006


>> [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: microformats-discuss-bounces at microformats.org
[mailto:microformats-discuss-bounces at microformats.org] 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 at microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss



More information about the microformats-discuss mailing list