RE: [uf-discuss] First version of Currency proposal

[Mike Schinkel]

>> I'm not that familiar with Wikis, they could probably implement a
per-page language setting.

The problem is not whether they can or cannot, but whether they will or
won't and whether the user (who won't be the developer in almost all cases)
will have the skill and/or motivation to make the change.  Same is true of
Content management systems (CMS) and Forums.

See here for how many Wikis and CMS and Forums would need to get updated:

http://www.wikimatrix.org/
http://www.cmsmatrix.org/
http://www.forummatrix.org/

I see it like how Microformats fundamental constraint is to not have to
change HTML so we can use them *now*.  I believe we've got to go with what
people can actually use today given the tools they are currently using w/o
fundamental change. 

>> The @lang doesn't have to be on the HTML element really. As long as it's
on *an* element that contains your content, a user-agent should know what's
going on.

If that's true, then that works!  An author could enclose everything they
type into a wiki page, CMS page, or forum post using a  like so:

 
The rain in Spain stays mainly in the plain.


-Mike
P.S. BTW, the issues with conent on Wikis and CMS and Forums is why this
proposal concerns me: http://gmpg.org/xmdp/  I have been planning to ask
about it as soon as I had a chance to study it.





-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ciaran
McNulty
Sent: Friday, October 20, 2006 5:14 AM
To: Microformats Discuss
Subject: Re: [uf-discuss] First version of Currency proposal

On 10/20/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:
> Question: how would someone implement a wiki with different pages in
different languages since they don't have access to changing the header or
 element for each wiki page?

I'm not that familiar with Wikis, they could probably implement a per-page
language setting.

The @lang doesn't have to be on the HTML element really. As long as it's on
*an* element that contains your content, a user-agent should know what's
going on.

-Ciaran McNulty
___
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

Re: [uf-discuss] First version of Currency proposal

[Ciaran McNulty]

On 10/20/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:

Question: how would someone implement a wiki with different pages in different 
languages since they don't have access to changing the header or  element 
for each wiki page?


I'm not that familiar with Wikis, they could probably implement a
per-page language setting.

The @lang doesn't have to be on the HTML element really. As long as
it's on *an* element that contains your content, a user-agent should
know what's going on.

-Ciaran McNulty
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] First version of Currency proposal

[Mike Schinkel]

Cool, thanks.

>> 

Question: how would someone implement a wiki with different pages in different 
languages since they don't have access to changing the header or  element 
for each wiki page?

-Mike

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ciaran McNulty
Sent: Friday, October 20, 2006 4:34 AM
To: Microformats Discuss
Subject: Re: [uf-discuss] First version of Currency proposal

On 10/20/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:
> Question: How does a human currently interpret a website that is have 
> values such as $1,000 when it it was designed by a US company with US 
> customers in mind? Is there something in the HTTP headers that makes 
> this explicit that a machine could read, or does the Argentine viewing 
> the web page just have to figure it out in context?  If not, then we'd 
> need a page-global currency seperator too...

The @lang attribute specifies an ISO639[1] or ISO3166[2] country code for the 
element it's applied to (and any descendant elements.

The W3C recommend[3] that the HTML element have this for every page.

You could easily, for instance have:


[...]
This product is $1,000 (1.500€) [...] 

And hopefully a user agent would know how to parse the numbers.  @lang also has 
benefits for things like screen readers and so on.

-Ciaran McNulty

  [1] http://ftp.ics.uci.edu/pub/ietf/http/related/iso639.txt
  [2] http://ftp.ics.uci.edu/pub/ietf/http/related/iso3166.txt
  [3] http://www.w3.org/International/O-HTML-tags.html
___
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

Re: [uf-discuss] First version of Currency proposal

[Ciaran McNulty]

On 10/20/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:

Question: How does a human currently interpret a website that is have values
such as $1,000 when it it was designed by a US company with US customers in
mind? Is there something in the HTTP headers that makes this explicit that a
machine could read, or does the Argentine viewing the web page just have to
figure it out in context?  If not, then we'd need a page-global currency
seperator too...


The @lang attribute specifies an ISO639[1] or ISO3166[2] country code
for the element it's applied to (and any descendant elements.

The W3C recommend[3] that the HTML element have this for every page.

You could easily, for instance have:


[...]
This product is $1,000 (1.500€)
[...]


And hopefully a user agent would know how to parse the numbers.  @lang
also has benefits for things like screen readers and so on.

-Ciaran McNulty

 [1] http://ftp.ics.uci.edu/pub/ietf/http/related/iso639.txt
 [2] http://ftp.ics.uci.edu/pub/ietf/http/related/iso3166.txt
 [3] http://www.w3.org/International/O-HTML-tags.html
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Ciaran McNulty]

On 10/20/06, Emiliano Martinez Luque <[EMAIL PROTECTED]> wrote:


That example in particular might not be a problem but consider the following:

$1,000

In the US that will mean one dollar, in Argentina (where I'm from) it
will mean a thousand dollars. And tying this to the currency
identification (even though the first 2 letters represent a country)
will not solve the issue, since I should be able to markup values in
different currencies within a single web page. I do agree though that
there should be some sort of optimization.


Actually it's 1000 in America too ;-)  There are plenty of other
countries where your assertion is true, though.

However I'm not convinced that the problem of number-parsing needs to
be solved in a microformat.  The @lang attribute already exists in
HTML and should indicate which locale numeric values are being written
in.  This would then hopefully also cover more complex cases like
figures written in Japanese etc.

-Ciaran McNulty
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] First version of Currency proposal

[Mike Schinkel]

>> $1,000
>> In the US that will mean one dollar, in Argentina (where I'm from) it
will mean a thousand dollars. 

I believe you misunderstood what I was proposing; a shorthand for cases
where it was unambiguous.  When it was ambiguous it would require more.
Unless I misunderstand, you would almost never use three decimal places for
money and if you did you'd need to use the unambiguous version.  Right?

>> I do agree though that there should be some sort of optimization.

It's becoming clearer and clearer to me that this is essential.

Question: How does a human currently interpret a website that is have values
such as $1,000 when it it was designed by a US company with US customers in
mind? Is there something in the HTTP headers that makes this explicit that a
machine could read, or does the Argentine viewing the web page just have to
figure it out in context?  If not, then we'd need a page-global currency
seperator too...

-Mike
P.S. I apologize on behalf of myself and my countrymen for us being so
USA-centric, but we unfortunately are. Hopefully globalization will open our
eyes and change that before much longer.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Emiliano
Martinez Luque
Sent: Friday, October 20, 2006 12:29 AM
To: Microformats Discuss
Subject: Re: [uf-discuss] First version of Currency proposal

> This gives me a chance to ask in a different way, why can we not 
> assume type=USD, amount=5.99, and symbol=$ from the following?
>
>The book costs $5.99
>

That example in particular might not be a problem but consider the
following:

$1,000

In the US that will mean one dollar, in Argentina (where I'm from) it will
mean a thousand dollars. And tying this to the currency identification (even
though the first 2 letters represent a country) will not solve the issue,
since I should be able to markup values in different currencies within a
single web page. I do agree though that there should be some sort of
optimization.
___
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

Re: [uf-discuss] First version of Currency proposal

[Emiliano Martinez Luque]

This gives me a chance to ask in a different way, why can we not assume
type=USD, amount=5.99, and symbol=$ from the following?

   The book costs $5.99



That example in particular might not be a problem but consider the following:

$1,000

In the US that will mean one dollar, in Argentina (where I'm from) it
will mean a thousand dollars. And tying this to the currency
identification (even though the first 2 letters represent a country)
will not solve the issue, since I should be able to markup values in
different currencies within a single web page. I do agree though that
there should be some sort of optimization.
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] First version of Currency proposal

[Mike Schinkel]

>>I believe you answer will be "what about unicode where we are not using 
>>[A-Za-z0-9] and if so, I would say that is when you add a symbol. In my 
>>example,  is the non-[A-Za-z0-9] character(s) *if* no symbol is 
>>explicitly specified. Can you give me an example where that would not 
>>work?
>yy $zz 5.99
>Where yy and zz are, say Japanese or Urdu characters (where zz might mean,
again for example, "approximately).

I'm sorry, I made a mistake in my question. I didn't mean to say is non
[digits+periods+commas] (I don't know how to write the regex at the
moment.).  So in your example, clearly it would require specifying the
symbol.  But when only digits and seperators?

-Mike



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andy
Mabbett
Sent: Saturday, October 14, 2006 4:04 PM
To: Microformats Discuss
Subject: Re: [uf-discuss] First version of Currency proposal

In message <[EMAIL PROTECTED]>, Mike Schinkel
<[EMAIL PROTECTED]> writes

>This gives me a chance to ask in a different way, why can we not assume 
>type=USD, amount=5.99, and symbol=$ from the following?
>
>   The book costs $5.99
>
>I believe you answer will be "what about unicode where we are not using 
>[A-Za-z0-9] and if so, I would say that is when you add a symbol. In my 
>example,  is the non-[A-Za-z0-9] character(s) *if* no symbol is 
>explicitly specified. Can you give me an example where that would not 
>work?

yy $zz 5.99

Where yy and zz are, say Japanese or Urdu characters (where zz might mean,
again for example, "approximately).

--
Andy Mabbett
Say "NO!" to compulsory ID Cards:  <http://www.no2id.net/>

Free Our Data:  <http://www.freeourdata.org.uk>
___
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

Re: [uf-discuss] First version of Currency proposal

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Mike Schinkel
<[EMAIL PROTECTED]> writes

>This gives me a chance to ask in a different way, why can we not assume
>type=USD, amount=5.99, and symbol=$ from the following?
>
>   The book costs $5.99
>
>I believe you answer will be "what about unicode where we are not using
>[A-Za-z0-9] and if so, I would say that is when you add a symbol. In my
>example,  is the non-[A-Za-z0-9] character(s) *if* no symbol is
>explicitly specified. Can you give me an example where that would not
>work?

yy $zz 5.99

Where yy and zz are, say Japanese or Urdu characters (where zz might
mean, again for example, "approximately).

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] First version of Currency proposal

[Mike Schinkel]

>> The book costs $5.99 

This gives me a chance to ask in a different way, why can we not assume
type=USD, amount=5.99, and symbol=$ from the following?

The book costs $5.99  

I believe you answer will be "what about unicode where we are not using
[A-Za-z0-9] and if so, I would say that is when you add a symbol. In my
example,  is the non-[A-Za-z0-9] character(s) *if* no symbol is
explicitly specified. Can you give me an example where that would not work?

-Mike

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andy
Mabbett
Sent: Saturday, October 14, 2006 6:53 AM
To: Microformats Discuss
Subject: Re: [uf-discuss] First version of Currency proposal

In message
<[EMAIL PROTECTED]>, Emiliano
Martinez Luque <[EMAIL PROTECTED]> writes

>Regarding the Straw man proposal, the symbol class seems to be 
>unnecesary since the symbol in most price representations is just a 
>convention to define which currency we are speaking of.

Not so. Suppose there is a page with the markup (simplified):

The book costs $5.99

and I have a user agent (a Firefox extension, say) which replaces the dollar
value with the value in pounds sterling. I'd get:

The book costs $£3.50

which is clearly nonsense.

By wrapping the dollar sign in a span (or whatever) with the class "symbol",
the user agent is made aware of its presence, and can hide it when inserting
the sterling value.

Likewise for the "unit" in

50 cents
--
Andy Mabbett
Say "NO!" to compulsory ID Cards:  <http://www.no2id.net/>

Free Our Data:  <http://www.freeourdata.org.uk>
___
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

Re: [uf-discuss] First version of Currency proposal

[Andy Mabbett]

In message
<[EMAIL PROTECTED]>, Emiliano
Martinez Luque <[EMAIL PROTECTED]> writes

>Regarding the Straw man proposal, the symbol class seems to be
>unnecesary since the symbol in most price representations is just a
>convention to define which currency we are speaking of.

Not so. Suppose there is a page with the markup (simplified):

The book costs $5.99

and I have a user agent (a Firefox extension, say) which replaces the
dollar value with the value in pounds sterling. I'd get:

The book costs $£3.50

which is clearly nonsense.

By wrapping the dollar sign in a span (or whatever) with the class
"symbol", the user agent is made aware of its presence, and can hide it
when inserting the sterling value.

Likewise for the "unit" in

50 cents
-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Scott Reynen]

On Oct 13, 2006, at 1:55 AM, Karl Dubost wrote:

There are also issues in the way you divide numbers. In many  
countries, number are organized by sequence of 3 digits. For  
example, in Japan


  10 yen = ju(10) yen
1000 yen = ichi(1) sen yen
but1 yen = ichi(1) man yen (and not ju sen yen)


 1   万　　　man
  1000   千　　　sen


And this is actually used in daily life, in case people think its a  
corner case.


Good point.  Can we get some examples of Japanese currency publishing  
in the wiki?  I'd lean towards making this machine-readable without  
listing every unit for every currency, e.g.:


一千title="JPY">¥


Otherwise, we face the task of defining currency units, and that's  
likely to be a huge headache for us and I think actually more work  
for publishers to track down the appropriate unit symbol.  Consider  
also:


The car costs $20k.
I sold my old baseball cards for five benjamins.
The war has cost $500 billion so far.

These will require either special pre-defined units for "k,"  
"benjamins," and "billion" or use of  to provide a machine- 
readable equivalent in a standard (dollar) unit.  I think the latter  
is much simpler.


Peace,
Scott

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Karl Dubost]

Le 06-10-12 à 23:18, Scott Reynen a écrit :

99¢


This is the sort of absurdity that the credit card advertisers
engage in.


I'm not sure what this means.  Do you not think 99¢ means  
fundamentally the same thing as 0.99USD?



What you see is 99 and what you get is less than 1.


That's only true if you consider the value outside the context of  
the currency, and I don't know why anyone would do that.  "99" is a  
meaningless monetary value without a currency assigned.  If the  
currency is going to be optional, I think it at least needs to be  
implied.  Otherwise we just have a number with no idea what it  
means.  And if there's an established currency, then why not use  
the unit already explicitly defined by that currency's ISO 4217  
code?  Why throw away the "D" in "USD"?


http://en.wikipedia.org/wiki/ISO_4217
"The first two letters of the code are the two letters of ISO 3166-1  
alpha-2 country codes"


There are also issues in the way you divide numbers. In many  
countries, number are organized by sequence of 3 digits. For example,  
in Japan


  10 yen = ju(10) yen
1000 yen = ichi(1) sen yen
but1 yen = ichi(1) man yen (and not ju sen yen)


 1   万　　　man
  1000   千　　　sen

wa-on kan-onmandarin
 1 一   hito   ichi yi
 2 二   futa   ni   ar, liang *
 3 三   mi san  san
 4 四   yonshi *si
 5 五   itsutsugo   wu
 6 六   mu roku liu
 7 七   nana   shichi * qi
 8 八   ya hachiba
 9 九   kokonotsu  kyuu jiu
10 十   toujyuu shi


And this is actually used in daily life, in case people think its a  
corner case.


--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
  QA Weblog - http://www.w3.org/QA/
 *** Be Strict To Be Cool ***




___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Guillaume Lebleu]

Scott Reynen wrote:
99class="currency" title="USD">¢


My bad. I had missed the title="0.99" part earlier. This will work for 
all currency amounts of recent times, as all currencies are now 
officially or de facto decimalized (UK was one of the last ones in 1971, 
see http://en.wikipedia.org/wiki/Decimalization), and indeed saves us 
from talking about units for now.


Thank you,

Guillaume
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Scott Reynen]

On Oct 12, 2006, at 7:35 AM, Al Gilman wrote:


99¢


This is the sort of absurdity that the credit card advertisers
engage in.


I'm not sure what this means.  Do you not think 99¢ means  
fundamentally the same thing as 0.99USD?



What you see is 99 and what you get is less than 1.


That's only true if you consider the value outside the context of the  
currency, and I don't know why anyone would do that.  "99" is a  
meaningless monetary value without a currency assigned.  If the  
currency is going to be optional, I think it at least needs to be  
implied.  Otherwise we just have a number with no idea what it  
means.  And if there's an established currency, then why not use the  
unit already explicitly defined by that currency's ISO 4217 code?   
Why throw away the "D" in "USD"?



Don't go there.  Maintain the functional integrity of the
construction, or you will generate lots of errors through
uncomprehending use.


In my above example, the publisher only needs to understand the  
relationship between dollars and cents (just like I need to  
understand the relationship between "January 1, 2000" and  
"2000-01-01").  In the example with an additional units property, the  
publisher only needs to know the standard symbol for their unit of  
choice (e.g. "cent").  I think the former knowledge is much more  
common than the latter.


We don't even know the latter ourselves.  If we're going to allow  
various units within any given currency, how would publishers (and  
parsers) know which units are commonly accepted, and what are the  
common symbols for identifying those units?  Are we going to create  
our own list of every possible currency unit?  If there isn't an  
existing standard here, that might be a good indication that there  
isn't a need for a standard here, because conversion to the default  
unit is a common and trivial practice.


How many currencies are we even talking about here anyway?  Looking  
at the ISO 4217 list, it seems to me most of these currencies (maybe  
80%?) only have one unit to choose, which suggests to me that  
allowing for communication in other units is an unnecessary  
complication.  Are there really enough multi-unit currencies that  
it's worth trying to standardize the non-default units?


Peace,
Scott___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Stephen Paul Weber]

>I'll repeat my example here, because it doesn't require altering the
>published content at all:
>
>99class="currency" title="USD">¢

This is the sort of absurdity that the credit card advertisers
engage in.  What you see is 99 and what you get is less than 1.
Don't go there.  Maintain the functional integrity of the
construction, or you will generate lots of errors through
uncomprehending use.


Actually, his example makes perfect sense.  99¢ == 0.99$ and since USD
== $ therefore the client app will either end up reading 0.99 out of
the data (as in his example) or converting 99¢ to 0.99 so that it can
work with it... which amounts to the same thing, the second is just
more code.  There is no absurdity present.  In fact, to force code to
convert centrs to dollars when dollars could have easily been encoded
in the original format seems almost absurd.  Although either works.
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Al Gilman]

Scott,

I am sorry, but your example is a very good "reductio ad absurdum"
argument against what you are advocating.

At 11:51 PM 2006-10-11, Scott Reynen wrote:

On Oct 11, 2006, at 6:33 PM, Guillaume Lebleu wrote:


Scott Reynen wrote:

So which of these tasks should we aim to make simple?  I'd say the
latter, because it's far more common (well over 80%, I think).

I think we agree here. $99 is more common than 99c, so the former
should be simpler to microformat than the latter. Where it seems we
differ in opinion is that the latter should still be possible to
microformat.


I don't think disagree there at all, and I'm not sure where you got
that impression.


To paraphrase you, what is simpler? to give a solution, although a
bit less simple, to the minority of people who uses "99c", or to
ask them to change the way they do things and use "$0.99"? I
believe in the former.


I'll repeat my example here, because it doesn't require altering the
published content at all:

99¢


This is the sort of absurdity that the credit card advertisers
engage in.  What you see is 99 and what you get is less than 1.
Don't go there.  Maintain the functional integrity of the
construction, or you will generate lots of errors through
uncomprehending use.



That would be displayed as: 99¢, just like your examples.  It doesn't
prevent anyone from using the microformat.  It just requires them to
provide a machine-readable equivalent in the standard dollar unit,
just like we provide machine-readable date equivalents in the
standard ISO 8601 format, despite published date formats varying widely.


I think you'll agree that the following is pretty simple:

$class="amount">99


And most people in this community seems to be in agreement with this.


I haven't seen anyone disagree with this.


Now, what do we offer to people who use amounts in U.S. cents on
their Web site.


Have them provide dollar equivalents in abbr titles, while
maintaining the exact same published content.


Nothing or something?


No one is suggesting nothing, so I'm not sure why you're discussing
that option here.

If we want to offer something, then for "70 US cents" as in http:// 
www.smh.com.au/articles/2004/07/01/1088488063161.html? from=storylhs, we 
could have:


70 US cents


We could, but what are the advantages of this over the example above?


The advantage is transparency: what you see is what you get.

The semantic construction of the value you are talking about is.

amount
 -- subcategory: currency
 -- measure: US cent == US$ / 100
 -- count == 70

in other words,

text\amount\currency\numberOf(US$/100 a.k.a. cent):70

You should be able to validate the relationship between what you see and
what you get (if they are stated differently) from (possibly a chain of)
mutually understood (by business and by consumer) relationships, such as
"divided by 100."  Not just define them separately and independently.

This gives both the consumer and the business the ability to detect and
purge errors.

Al





My 2 cents


My 0.02 dollars.

Peace,
Scott___
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

Re: [uf-discuss] First version of Currency proposal

[Scott Reynen]

On Oct 11, 2006, at 6:33 PM, Guillaume Lebleu wrote:


Scott Reynen wrote:
So which of these tasks should we aim to make simple?  I'd say the  
latter, because it's far more common (well over 80%, I think).
I think we agree here. $99 is more common than 99c, so the former  
should be simpler to microformat than the latter. Where it seems we  
differ in opinion is that the latter should still be possible to  
microformat.


I don't think disagree there at all, and I'm not sure where you got  
that impression.


To paraphrase you, what is simpler? to give a solution, although a  
bit less simple, to the minority of people who uses "99c", or to  
ask them to change the way they do things and use "$0.99"? I  
believe in the former.


I'll repeat my example here, because it doesn't require altering the  
published content at all:


99class="currency" title="USD">¢


That would be displayed as: 99¢, just like your examples.  It doesn't  
prevent anyone from using the microformat.  It just requires them to  
provide a machine-readable equivalent in the standard dollar unit,  
just like we provide machine-readable date equivalents in the  
standard ISO 8601 format, despite published date formats varying widely.



I think you'll agree that the following is pretty simple:

$abbr>99


And most people in this community seems to be in agreement with this.


I haven't seen anyone disagree with this.

Now, what do we offer to people who use amounts in U.S. cents on  
their Web site.


Have them provide dollar equivalents in abbr titles, while  
maintaining the exact same published content.



Nothing or something?


No one is suggesting nothing, so I'm not sure why you're discussing  
that option here.


If we want to offer something, then for "70 US cents" as in http:// 
www.smh.com.au/articles/2004/07/01/1088488063161.html? 
from=storylhs, we could have:


70 class="currency" title="USD">US title="cent">cents


We could, but what are the advantages of this over the example above?


My 2 cents


My 0.02 dollars.

Peace,
Scott___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Emiliano Martinez Luque]

My message with corrected markup. Please disregard the other one.

Regarding the Straw man proposal, the symbol class seems to be
unnecesary since the symbol in most price representations is just a
convention to define which currency we are speaking of. So there is no
actual need to explicitly mark it up as such, since User agents can
(quite simply) derive it from the ISO code in any transformations that
they might need to do. This is so, regardless of whether the symbol is
present or not in the actual text. ie:


$100 and 99 cents


Can be interpreted the same way by the User Agent as:


$100 and 99 cents


Since the currency symbol can be derived from the ISO Currency code.

The same thing can be said of the unit class in both proposals.
Guillaume's example from his last mail:

70 US cents


Can be Marked up, quite consistently as:

70 US cents

Since 0.70 USD is 70 cents. Remember that there might be text within a
microformat that is to be discarded by a User Agent.  An example of
this from the hCard specification:

Home (preferred):
+1.415.555.1212


The "erred):" text outside the type proprety is to be discarded by the
User Agent.

One thing I notice is that both in the Straw man proposal and in
Gillaume's one, there is still the problem of how amounts are
differently expressed across different countries. ie: 1,000.99 or
1.000,99 to represent a thousand and 99 cents of the currency.

Has any thought been given of linking this to the language definition
of the document (similar to the way that OSs handle locale)?. Ie:

http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="en-US" lang="en-US">


On Sale now for: 
€100.99


http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="es-AR" lang="es-AR">


Oferta: 
€100,99


Should both be understood as 100.99 EUR.

And If some markup falls outside the scope of the locale it can be
explicitelly marked up with the amount class.

What do you think of this idea? Does any other solution has been
proposed for this problem?

Emiliano Martínez Luque

PS: Sorry about the other mail.
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Emiliano Martinez Luque]

I've just realized that the markup in my examples is wrong.. since I'm
using title to define a value on the span element where I should be
using the abbr element. I'm sorry about that, I was thinking more
along the lines on how to parse the format than the actual mark up.

Emiliano Martínez Luque
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Lachlan Hunt]

Guillaume Lebleu wrote:

Please find it at: http://microformats.org/wiki/currency-proposal


For tables of currency, I don't like the global definition method 
suggested.  Tables cells have the scope and headers attributes 
available, so we should use them where possible.


See, for example, this table of exchange rates, where each column 
represents one currency.


http://au.finance.yahoo.com/currency

The top row of headers could be marked up like this (ignoring the links 
they also use for simplicity):


US$

Then every cell in that column can now automatically be a unit given in 
USD, and there is no need for the extra complexity of the include pattern.


(It could also be implemented using the headers attribute on each cell, 
referencing the  using its ID.)


For referencing a unit defined elsewhere in the document, so that you 
don't have to give it for every occurrence (especially where it's not 
within a table like that above), the WHATWG is defining the Web Apps 
spec a nice feature using  and .


e.g.
This is the defining instance of the unit:
  
$39.00
  

And this is a cross reference to that in the same document:
  $42.00

http://www.whatwg.org/specs/web-apps/current-work/#the-dfn
http://www.whatwg.org/specs/web-apps/current-work/#the-abbr

Finally, I don't think the  is necessary at all. 
The spec can just define that everything within , 
excluding the "currency" and "unit" values, is the amount.  We need to 
be careful not to add too many spans and classes everywhere, because it 
only makes the microformat harder to use.


--
Lachlan Hunt
http://lachy.id.au/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Emiliano Martinez Luque]

Hi, I have just finnished reading both proposals, and here are some of
my thoughts.

Regarding the Straw man proposal, the symbol class seems to be
unnecesary since the symbol in most price representations is just a
convention to define which currency we are speaking of. So there is no
actual need to explicitly mark it up as such, since User agents can
(quite simply) derive it from the ISO code in any transformations that
they might need to do. This is so, regardless of whether the symbol is
present or not in the actual text. ie:


$100 and 99 cents


Can be interpreted the same way by the User Agent as:

100.99

The same thing can be said of the unit class in both proposals.
Guillaume's example from his last mail:

70 US cents

Can be Marked up, quite consistently as:

70 US cents

Since 0.70 USD is 70 cents. Remember that there might be text within a
microformat that is to be discarded by a User Agent.  An example of
this from the hCard specification:

Home (preferred):
+1.415.555.1212


The "erred):" text outside the type proprety is to be discarded by the
User Agent.

One thing I notice is that both in the Straw man proposal and in
Gillaume's one, there is still the problem of how amounts are
differently expressed across different countries. ie: 1,000.99 or
1.000,99 to represent a thousand and 99 cents of the currency.

Has any thought been given of linking this to the language definition
of the document (similar to the way that OSs handle locale)?. Ie:

http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="en-US" lang="en-US">


On Sale now for: 
$100.99


http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="es-AR" lang="es-AR">


Oferta: 
US$100,99


Should both be understood as 100.99 EUR.

And If some markup falls outside the scope of the locale it can be
explicitelly marked up with the amount class.

What do you think of this idea? Does any other solution has been
proposed for this problem?

Emiliano Martínez Luque
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Lachlan Hunt]

Scott Reynen wrote:

On Oct 11, 2006, at 2:43 PM, Guillaume Lebleu wrote:


Can we just treat everything as the default unit

>
Not sure what you mean in the context of the 99c example. The default 
unit for the US currency is the Dollar, not the Cent, but in the 
context of the 99c context, we need to ensure that "Dollar" is not 
picked as the unit, but "Cent" instead is.


What I'm suggesting is that everything be treated as dollars in USD and 
everything be treated as Yen in JPY.  Isn't that how most applications 
and people deal with money anyway?


No, not everyone.  See, for example, Fuel Watch [1] which list all the 
prices in cents per litre.  For them, changing it to dollars would 
probably be a little confusing because fuel prices are given everywhere 
in the country as cents per litre.


[1] http://fuelwatch.com.au/

--
Lachlan Hunt
http://lachy.id.au/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Guillaume Lebleu]

Scott Reynen wrote:
So which of these tasks should we aim to make simple?  I'd say the 
latter, because it's far more common (well over 80%, I think).
I think we agree here. $99 is more common than 99c, so the former should 
be simpler to microformat than the latter. Where it seems we differ in 
opinion is that the latter should still be possible to microformat.


To paraphrase you, what is simpler? to give a solution, although a bit 
less simple, to the minority of people who uses "99c", or to ask them to 
change the way they do things and use "$0.99"? I believe in the former.


I think you'll agree that the following is pretty simple:

$class="amount">99


And most people in this community seems to be in agreement with this. 
See currency-brainstorming


Now, what do we offer to people who use amounts in U.S. cents on their 
Web site.


Nothing or something?

If the community agrees it is a rarity, then we may want to just offer 
nothing (hopefull the poll I sent will provide useful feedback to this 
question).


Users will come up with something themselves if the community was wrong. 
I have seen at least one web page where the cents part of the price was 
marking up (even when represented like "$39.99") to display the .99 as 
superscript - I'll try to find this again and document it in examples.


If we want to offer something, then for "70 US cents" as in 
http://www.smh.com.au/articles/2004/07/01/1088488063161.html?from=storylhs, 
we could have:


70 class="currency" title="USD">US title="cent">cents


This is slightly more complex, but after all, people using this are 
relatively few.


Now, what about "70 cents". I suggested using an empty abbreviation that 
was not well received, but an include link to a hidden global definition 
would work as well:


$

70 title="cent">cents 


That's a bit more complex, but at least there is something for the 
minority to follow. And my experience with standards is that if there is 
something that the community defined, and it works for a user's 
particular problem, then the user tends to go with it.


My 2 cents,

Guillaume








Peace,
Scott
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


--No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.407 / Virus Database: 268.13.1/466 - Release Date: 10/7/2006




___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Scott Reynen]

On Oct 11, 2006, at 4:13 PM, Guillaume Lebleu wrote:

There are some examples on the Web that make use of cents, and my  
design philosophy with this proposal was to make simple things  
simple to microformat, and complex things possible to microformat,  
without requiring publishers to change some of their practices


While a nice design philosophy in general, I don't think "make simple  
things simple" means very much outside the context of what exactly is  
being made simple.  What qualifies as "simple" depends on what you're  
trying to accomplish.  If you're trying to publish monetary values as  
cents, converting those values to dollars to make them machine  
readable is less simple than telling the machine that they're cents  
(assuming there is a standard way to indicate cents, which we don't  
currently seem to have).  But if you're trying to publish monetary  
values as dollars, stating that your unit is dollars is less simple  
than assuming that's the case (or interpreting as much from the "D"  
in "USD").  So which of these tasks should we aim to make simple?   
I'd say the latter, because it's far more common (well over 80%, I  
think).


Peace,
Scott
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Guillaume Lebleu]

Andy Mabbett wrote:

How does this relate to the proposal in:

http://microformats.org/wiki/currency-brainstorming#Straw_man_proposal
  

Hello Andy,

I added an acknowledgment section that links to your strawman proposal.

To answer your question about how it relates to your strawman proposal, 
I think it is very close to it:


   * It has the same money class name you described
   * It has the same amount class name you described with same usage
 (required)
   * It has the date you suggested with the design pattern you suggested
   * "symbol" class name omitted with the objective of simplifying the
 first version as it was not present in most brainstorming suggestions
   * "unit" class name same as the one you described with more details,
 as you have read like me, some in the community are discussing the
 value of this one, so we may omit it in the first version as well.
   * equivalence: your text was questioning whether we needed this, so
 for simplicity it was omitted in this first version.

In terms of the issues you mentioned in your strawman proposal:

   * I thought that postponing support for currencies that are no
 longer officially in use was fair for the purpose of simplifying
 the first version.
   * For tables, I suggested we reuse the include design pattern. This
 allows to markup the typical legend found next to tables "(amount
 in $)" and refer to it later. It is more consistent than allowing
 the ISO 4217 to be also a class name. I remember from the list
 that I am not the only one to argue that "USD" is content, not a
 class name.

Regarding issues in the mailing list, I can only talk for the issues 
that were discussed over the last 2 months, and I believe they were 
incorporated, as I followed these discussions very closely. Primarily, I 
put aside in the separate thread (measure) everything related to 
combinations of money and units, such as in prices.


If you think this proposal is missing some issues that must be 
absolutely addressed for the first version, let me know.


Thank you,

Guillaume


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Guillaume Lebleu]

Scott Reynen wrote:
What I'm suggesting is that everything be treated as dollars in USD 
and everything be treated as Yen in JPY.  Isn't that how most 
applications and people deal with money anyway?



I think this will indeed work in most cases.

There are some examples on the Web that make use of cents, and my design 
philosophy with this proposal was to make simple things simple to 
microformat, and complex things possible to microformat, without 
requiring publishers to change some of their practices:

- http://www.99only.com/
- http://www.smh.com.au/articles/2004/07/01/1088488063161.html?from=storylhs

But we certainly could, if this is the consensus of this community, to 
enforce that all microformatted money amounts be expressed in the 
default unit of each currency.


What I have seen in other standardization processes, is the 
documentation of the different options explored with benefits/drawbacks 
for each, to allow easy side-by-side comparison by the community. I 
think this will be my next step.


Guillaume
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Andy Mabbett]

In message <[EMAIL PROTECTED]>, Guillaume Lebleu
<[EMAIL PROTECTED]> writes

>Please find it at: http://microformats.org/wiki/currency-proposal

How does this relate to the proposal in:

http://microformats.org/wiki/currency-brainstorming#Straw_man_proposal

It doesn't even seem to link to the page on which the latter sits, and
seems to disregard a number of other issues raised on that page and in
mailing list discussion.
-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Scott Reynen]

On Oct 11, 2006, at 2:43 PM, Guillaume Lebleu wrote:


Can we just treat everything as the default unit
Not sure what you mean in the context of the 99c example. The  
default unit for the US currency is the Dollar, not the Cent, but  
in the context of the 99c context, we need to ensure that "Dollar"  
is not picked as the unit, but "Cent" instead is.


What I'm suggesting is that everything be treated as dollars in USD  
and everything be treated as Yen in JPY.  Isn't that how most  
applications and people deal with money anyway?  If you want to  
consider your money as cents in your own publishing or your own  
application, you can make the simple conversion (multiply or divide  
by 100) necessary to use the microformat's assumed unit of dollar.   
Is there any currency with multiple units that aren't simple and  
constant fractions of a standard unit?



and adjust the machine-readable values accordingly?  E.g.:

99abbr>¢


So using this notation would require the parser to interpret the ¢  
as the cent unit of the USD currency without this information being  
disambiguated using a microformat.


It seems like you're making this more complicated than it needs to  
be.  The amount is 0.99.  That's an amount in the dollar unit, which  
would be assumed for all USD currency.  There is no cent unit here,  
and no requirement to interpret a cent unit.  When you say "99¢," do  
you mean anything that isn't a direct equivalent of $0.99?  Why  
should a parser care what symbols you use to convey that meaning?  If  
everyone uses the same unit, communication will be much easier, and  
I'm not seeing any reason everyone can't do easily use the same unit  
for machines.  It seems most publishers (well over 80%) already use  
the same unit for people, and the edge cases can convert for machines  
using  just like we all convert to a standard date format for  
machines.


It would certainly work, assuming you can deal with the different  
way of representing the "Cent" information


Doesn't the word "cent" literally mean one perCENT of a "dollar"?   
I'm not seeing the benefit of treating "cent" as a distinct unit.


but isn't our goal here to make interpretation easier, and not  
require to have to deal with all these tiny differences?


Yes, and I'd say the concept of a "cent" is a tiny difference that  
parsers shouldn't have to deal with when the concept of a "dollar"  
works just fine to communicate the exact same information.


Peace,
Scott

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Guillaume Lebleu]

Scott Reynen wrote:
Specifically, I don't think it makes sense to have the first  
tag with no title, and the second  with no content.  It looks 
like you're trying to communicate three different pieces of 
information when only two are really being published.  
Thank you for the feedback. Let me first clear up what I am trying to 
communicate here.


My rationale is that in "99 cents", the two pieces of information 
published are the amount and the unit of currency (See 
http://en.wikipedia.org/wiki/Cent_(currency)), not the amount and the 
currency. Without context, the currency piece of information in "99 
cents" could be U.S. currency, Australian currency, Canadian currency or 
Euro currency. This is what I am trying to reflect. See also: 
http://www.austlii.edu.au/au/legis/cth/consol_act/ca1965120/s8.html that 
clearly shows the distinction between the currency and the denomination.


The reason why there is no title attribute in class="unit">¢ in my example is b/c I don't want to get ahead of 
myself and leave this up to the measure proposal, but it should be class="unit" title="[some standard/agreed upon code for "cent"]">
Can we just treat everything as the default unit 
Not sure what you mean in the context of the 99c example. The default 
unit for the US currency is the Dollar, not the Cent, but in the context 
of the 99c context, we need to ensure that "Dollar" is not picked as the 
unit, but "Cent" instead is.

and adjust the machine-readable values accordingly?  E.g.:

99class="currency" title="USD">¢


So using this notation would require the parser to interpret the ¢ as 
the cent unit of the USD currency without this information being 
disambiguated using a microformat. It would certainly work, assuming you 
can deal with the different way of representing the "Cent" information, 
but isn't our goal here to make interpretation easier, and not require 
to have to deal with all these tiny differences?


Guillaume
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Scott Reynen]

On Oct 11, 2006, at 1:18 PM, Guillaume Lebleu wrote:

My intention is to have 2 class names, one for the currency (ex.  
U.S. currency), and one for the unit within that currency (ex.  
Dollar, Cent). "unit" is optional, b/c most currencies have a  
default unit (Dollar in the case of the U.S. currency).


I have added more details to the proposal on this. See: http:// 
microformats.org/wiki/currency-proposal


I'm not sure the example of this really works:

99¢ 



Specifically, I don't think it makes sense to have the first   
tag with no title, and the second  with no content.  It looks  
like you're trying to communicate three different pieces of  
information when only two are really being published.  Can we just  
treat everything as the default unit and adjust the machine-readable  
values accordingly?  E.g.:


99class="currency" title="USD">¢


Is there a currency example in which this wouldn't work?

Peace,
Scott

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[Guillaume Lebleu]

King Chung Huang wrote:



Is "currency unit" intended to be one whole name or two names? 


My intention is to have 2 class names, one for the currency (ex. U.S. 
currency), and one for the unit within that currency (ex. Dollar, Cent). 
"unit" is optional, b/c most currencies have a default unit (Dollar in 
the case of the U.S. currency).


I have added more details to the proposal on this. See: 
http://microformats.org/wiki/currency-proposal


Hope this helps.

Thank you for your feedback,

Guillaume


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] First version of Currency proposal

[King Chung Huang]

Hi Guillaume,

Is "currency unit" intended to be one whole name or two names? I  
believe specifying something with a class attribute value "currency  
unit" means it's of class "currency" and "unit", not "currency unit"  
as a whole. Maybe "currency-unit" or "currencyunit" would be better?


Cheers,

King Chung Huang
www.mobovivo.com

On 10-Oct-06, at 10:53 PM, Guillaume Lebleu wrote:


Please find it at: http://microformats.org/wiki/currency-proposal

Thank you in advance for your feedback.

Guillaume


___
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

[uf-discuss] First version of Currency proposal

[Guillaume Lebleu]

Please find it at: http://microformats.org/wiki/currency-proposal

Thank you in advance for your feedback.

Guillaume


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss