title attribute and abbreviated class names(Was:[uf-discuss]Currency Quickpoll: Preliminary results)

[Mike Schinkel]

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 &nbsp; like so: 

	s.replace(/&nbsp;/," ") 

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">$&nbsp;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">$&nbsp;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">$&nbsp;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 "$&nbsp;", 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
microformats-discuss at microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss