title attribute and abbreviated class
names(Was:[uf-discuss]Currency Quickpoll: Preliminary results)
Scott Reynen
scott at randomchaos.com
Tue Oct 17 07:30:15 PDT 2006
I've starting replying to this a few times and become stuck in trying
to fit what I'm trying to say in the existing thread, so I'm just
going to make some points completely detached from the thread.
First, I think Mike is right that the vast majority of published
money formats allow parsers to infer the distinction between the
currency symbol and the amount. But this inference is already
possible without a microformat. What's missing currently is:
1) an indication of which specific currency the symbol refers to.
2) the ability to markup money that doesn't fit this pattern
I think it's best to either cover #1 or both, but I think it's too
complicated for publishers to provide what amounts to two distinct
microformats depending on a relatively complex pattern definition.
That is, if we're going simple (only #1), I think we should go only
simple, and add the complex form to cover #2 later.
So to cover #1, Mike has suggested:
<span class="money" title="USD">$5.99</span>
I still think this is bad semantics. I don't think "USD" is really a
title for "$5.99". I'd propose this as an alternative:
<abbr class="currency" title="USD">$</abbr>5.99
That is, markup the currency as currency, and treat any adjacent
numbers as the amount.
To cover #2, I think we need an additional class="money" container,
and a class="amount" markup for the amount, and this could be added
without changing the parsing rules for the simple form I've suggested
above. I think it would be best to start with either simple or
complex and look at adding the alternative after the microformat has
gained some adoption.
I don't think regular expressions should be included in the spec at
all. If we're going to define amounts based on character ranges, we
should describe those character ranges in plain English because most
people, even most tech geeks, don't understand regular expressions at
all.
Peace,
Scott
On Oct 15, 2006, at 4:40 PM, Mike Schinkel wrote:
> 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: microformats-discuss-bounces at microformats.org
> [mailto:microformats-discuss-bounces at microformats.org] 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
More information about the microformats-discuss
mailing list