Scott:
Thanks for the reply. If probably got confusing on my part; I will try to
resolve that here if possible.
>> I thought what you suggested was to allow for explicit differentiation
>> between the currency identifier and the amount, but in certain cases where
>> such differentiation can be made by matching a regular expression, allow for
>> markup without explicit differentiation, leaving the differentiation
>> implicitly to the parser to figure out. For example, this would be
>> valid:... because it does follow the pattern, where everything that's not
>> within a certain character group is considered a currency symbol (i.e. "$").
>> If this isn't what you're suggesting, then I'm not clear on what you're
>> suggesting.
You got it 100%. But I did make a mistake in my example as I didn't mean to
include alpha [A-Za-z]. It should just have been digits, periods, and commas
[0-9\.\,]; everything else would be the currency symbol. I wasn't explicit
about the following, but I will be now; no spaces (or ) and the currency
figure must be contiguous and either prefix or suffix a collection of digits.
Anythings else, and you need the complexity.
Although I am not good with regex, I opened my regex book and my regex test and
crafted this regex which I think identifies 100% of the special case to which I
referred:
^([^0-9,\. ]*)([0-9]+[\.,]?[0-9]*)([^0-9,\. ]*)$
In that regex, if $2 has a value, that's the amount. If $1 OR $3 has a value,
then it's the symbol. If it doesn't match, you *must* use the complex form.
(btw, this would also be really easy to write a recursive descent and/or a
looping parser in javascript or other languages to parse this and we could
publish those reference implementations.) We publish the regex (or a better
written one) and the recursive descent parsers and say if it matches, you can
use the simple form, otherwise the complex
So the following could use the simple form:
The book is <span class="money" title="USD">$5.99</span>.
In Brazil, the book would be <span class="money"
title="BRL">R$12.84</span>.
In Denmark, the price would be <span class="money"
title="DKK">35.66kr</span>.
BTW, it wouldn't be hard to include spaces in the regex and it might be a good
idea to go ahead and do that. If so, you can use the javascript replace()
string function (or similar in other languages) to first normalize the string
to containing only real spaces and no like so:
s.replace(/ /," ")
where "s" is the innertext for the <span> and then use this regex on the result:
^([^0-9,\. ]*)[ ]?([0-9]+[\.,]?[0-9]*)[ ]?([^0-9,\. ]*)$
Where again $1 OR $3 will be the symbol and $2 will be the amount. That would
make these possible.
The book is <span class="money" title="USD">$ 5.99</span>.
In Brazil, the book would be <span class="money" title="BRL">R$
12.84</span>.
In Denmark, the price would be <span class="money" title="DKK">35.66
kr</span>.
Yes is it a little more difficult for the person writing the parser, but there
will be many times more orders of magnitude people writing the HTML than
parsers and besides, we can provide a working regex and reference
implementation functions that will be good for 99% of cases and just say "Here;
use it!"
>> http://regexlib.com/Search.aspx?k=currency
I reviewed that and it appears there are most regex submitted that do
essentially the same thing, correcting for something others didn’t do (like
handle leading zeros); did I misread?
>> and I think it's only helping a slight majority that is quickly becoming a
>> minority. English language web pages only comprise about 55% of the web
>> today, and that percent is quickly shrinking. So I'm publishing my currency
>> in English, and you're trying to ease my implementation burden, so I don't
>> have to explicitly define my currency symbol and parsers will just figure it
>> out for me.
I respectfully think it won't be in the minority; I think it will be the vast
majority. And it will work in others language besides English such as German,
Spanish, French, Porteguese, Russia, Arabic, and so on; any that use digits +
periods/commas for representing numbers. It seems the only languages in any
significant use that it doesn't work for is multibyte characters, which will
require the complexity because, frankly, they are complex.
>> I think this is already more confusing than just always identifying the
>> individual parts, I think it's still likely to cause problems, ..
Requiring identification of individual parts is less confusing in an abstract
manner because you don’t assume anything, but it is more difficult to learn
because it requires everyone that implements it grok the entire spec to be able
to use it. By offering a simpler version, (I assert that) most people won't
have to learn all the of the details because they will just use the simple
version. So it could be described as such:
The Money microformat has a simple version that applies in most cases,
and a complex
version for when you really need control or if you are using multibyte
character sets. You
can use the simple version, if the markup to which you want to add this
microformat is
limited to:
1.) currency symbols (i.e. $, £, etc.),
2.) spaces,
3.) digits (i.e. 0-9), and
3.) decimal seperators (comma "," or period ".")
For example:
The book is <span class="money" title="USD">$ 5.99</span>.
In Brazil, the book would be <span class="money" title="BRL">R$
12.84</span>.
In Denmark, the price would be <span class="money"
title="DKK">35.66 kr</span>.
If however you want to markup money represented in much more complex
ways, you'll need to
use the more complex version, for example:
<p class="money">It'll cost you <abbr class="money"
title="50.00">fifty</abbr>
<abbr class="amount" title="GBP">quid</abbr>, mate!</p>
<span class="money">Can you spare <abbr class="amount"
title="10">ten</abbr>
<abbr class="currency" title="USD"><span
class="unit">dollars</span></abbr>?</span>
By describing it this way, people who can use the simple version are never even
required to drill down and learn the complex way. This seems infinitely easier
for the vast majority of people than for them to have to grok the entire spec
right off the bat. Frankly, when I first saw it I thought "It isn't really
going to be this complex, is it? I though the theme behind microformats were
"Make the simpliest addition to HTML markup required." That's one of the
reasons I was so drawn to the initiative.
I actually think you'll end up with more invalid microformats if people are
required to implement the current proposal because it is complex enough that it
would be relatively easy for someone to get wrong. By having a simplier format,
you'll minimize the chance those people get it wrong, and that those who do go
to the more complex are more likely to really study it and get it write, and
there will be less people overloading the experts by asking less questions
about it (IMO).
Question: Maybe we should vet this with typical web developers who are NOT
involved with the microformat's initiative? We could go out and ask workaday
web site developers and web site maintainers their opinion on the subject of
what is easier to comprehend? Honestly, I'm giving my opinion but I could find
out my opinion is in a tiny minority. Or vice versa.
BTW, is there a plan to create a series of microformat validator pages where
someone could go and enter a URL and have it extract all the data it found for
a given microformat? Without this, I think people will end up creating lots of
pages with invalid microformat. And it would need to be done for *each*
microformat.
>> There are people from Yahoo! on this list, and Technorati's pretty big too,
>> so they'd be good people to say whether or not they really care how long the
>> class names are.
Yeah, I already said "Okay, concern addressed" in an earlier reply.
Anyway, I'm hoping that my earlier mistake of including [A-Za-z] was the main
reason you objected and that you'll agree with a small scope minimum form like
I'm proposing.
-Mike Schinkel
http://www.mikeschinkel.com/blog
http://www.welldesignedurls.org/
P.S. On another note, another question just occurred to me: why are you using
"money" and not "hMoney?"
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen
Sent: Saturday, October 14, 2006 10:39 PM
To: Microformats Discuss
Subject: Re: title attribute and abbreviated class
names(Was:[uf-discuss]Currency Quickpoll: Preliminary results)
On Oct 14, 2006, at 3:27 PM, Mike Schinkel wrote:
>>> Your examples seem to leave a lot of ambiguity about what things
>>> mean,
>
> I'm new to proposing microformats, so I clearly have a lot to learn,
> but that said I don't see where what I was proposing was ambiguous.
> Can you give me explicit examples where allowing default assumptions
> for the most common use cases will by necessity lead to ambiguity? It
> seems to me that either something will be specified or if not it will
> default? That seems non ambiguous to me. Am I wrong?
I'm not entirely sure we're talking about the same thing anymore, after reading
this exchange:
On Oct 14, 2006, at 3:55 PM, Mike Schinkel wrote:
>>> That said, why not make the "symbol" markup optional?
>
> That's IMO is an additional good idea.
I thought that was basically what you were advocating, but you called it an
/additional/ good idea, so I'm not sure what it's an addition to. I thought
what you suggested was to allow for explicit differentiation between the
currency identifier and the amount, but in certain cases where such
differentiation can be made by matching a regular expression, allow for markup
without explicit differentiation, leaving the differentiation implicitly to the
parser to figure out. For example, this would be valid:
本が<span class="money"><abbr class="amount" title="1000">一千</
abbr><abbr class="currency" title="JPY">円</abbr></span>
because it doesn't fit the pattern you suggested, but this would also be valid:
The book is <span class="money">$5.99</span>.
because it does follow the pattern, where everything that's not within a
certain character group is considered a currency symbol (i.e. "$"). If this
isn't what you're suggesting, then I'm not clear on what you're suggesting.
But if this is what you're suggesting, I think you're underestimating the
complexity involved in defining which characters might be part of an amount and
which characters might be part of a currency symbol. I do a lot of parsing via
regular expressions and a large part of my interest in microformats comes from
witnessing the failure rate in such parsing. There's always another unexpected
format popping up and before you know it, the regular expression is a page
long. See this page for a list of regular expressions for identifying the
information that needs to be parsed from currency values for a quick
taste:
http://regexlib.com/Search.aspx?k=currency
And those are all defining legitimate input much more strictly than would be
appropriate for the web at large.
To specifically answer your question of what doesn't work with [A-Za- z0-9],
there's the decimal point, which is part of the amount rather than the currency
symbol, and there's any commas, which are also part of the amount rather than
the currency symbol, and any whitespace characters (of which there are many)
shouldn't be considered part of the amount nor the currency symbol. That's all
I can think of right now, but I have no doubt there's much more I haven't
thought of, and it's that much more I'm worried about. So if we come up with a
definition that includes all of that, now we're talking about explaining to
authors that they can only leave out the currency markup if their class="money"
tag is only containing letters, numbers, decimal points, commas, and
whitespace. Otherwise they have to explicitly identify the individual parts.
I think this is already more confusing than just always identifying the
individual parts, I think it's still likely to cause problems, and I think it's
only helping a slight majority that is quickly becoming a minority. English
language web pages only comprise about 55% of the web today, and that percent
is quickly shrinking. So I'm publishing my currency in English, and you're
trying to ease my implementation burden, so I don't have to explicitly define
my currency symbol and parsers will just figure it out for me. What if I want
my whitespace to be marked up with HTML entities? E.g.:
The book costs <span class="money">$ 5.99</span>
That's not an unlikely scenario. I actually publish currency values like that,
when someone wants a space to separate the $ from the amount, but they don't
want the two getting split onto separate lines. Are we going to include that
in the regular expression too or do I need to explicitly identify my symbol?
If it's not allowed, how will that be explained clearly enough that I won't
make this mistake and wind up with my currency symbol wrongly interpreted as
"$ ", which doesn't map to any known currency, and will lose my space if
it's replaced by another currency symbol? This is the kind of ambiguity that
doesn't really help publishers. And if it is in the regular expression, how
are we going to explain to publishers that it's okay? Looks like unnecessary
complication to me.
> But one final point on this; has this been discussed this with those
> who make the decisions for markup used at the largest sites:
> Google, eBay,
> Amazon, etc.? Just curious? (and I don't mean to push this, it's just
> that being pedantic is in my nature, unfortunately. :)
There are people from Yahoo! on this list, and Technorati's pretty big too, so
they'd be good people to say whether or not they really care how long the class
names are.
Peace,
Scott_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
