Dated currency examples?

In message <C13C4877.7BB2E%tantekcs.stanford.edu>, Tantek
Çelik
<tantekcs.stanford.edu> writes

>date

How about this as a model:

        "date" is an optional component of the
"currency" microformat.

        When date is present, parsers may disregard it.

        When parsers understand date, and none is present,
they may
        infer the date from any containing element (e.g.
review, hAtom
        entry, hResume-hCalendar, etc.)
?
-- 
Andy Mabbett
                Say "NO!" to compulsory ID Cards: 
<http://www.no2id.net/>

                Free Our Data:  <http://www.freeourd
ata.org.uk>
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Sep 24, 2006, at 7:29 PM, Andy Mabbett wrote:

> In message <C13C4877.7BB2E%tantekcs.stanford.edu>, Tantek Çelik
> <tantekcs.stanford.edu> writes
>
>> date
>
> How about this as a model:
>
>         "date" is an optional component of
the "currency" microformat.
>
>         When date is present, parsers may disregard it.
>
>         When parsers understand date, and none is
present, they may
>         infer the date from any containing element
(e.g. review, hAtom
>         entry, hResume-hCalendar, etc.)
> ?

the problem I see with logic like the above is the one that
comes up  
semi-frequently when trying to address issues like this --
that a  
parser for X must then understand all other current (and
future)  
microformats in order to extract the proper meaning from the
markup.  
If you have a parser that understands hatom and hcalendar
and then  
hreview comes along it presents the case of ether (a) the
parser not  
extracting the meaning because it doesn't yet support the
newer  
format or (b) the page changing "meaning" to the
outside world as  
parsers get upgraded to see the new context.

I would also worry about being too ambitious with applying
context  
clues (e.g. a blog post stating "i remember buying a
comic book for  
10˘" and then applying the post date to the value) but
that may be  
more of an authoring issue that could be worked through with
more  
discussion then my first concern.

-- 
[ Chris Casciano ]
[ chrisplacenamehere.com ] [ http://placenamehere.com
]

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On 9/24/06 7:25 PM, "Chris Casciano" <chrisplacenamehere.com> wrote:

> 
> On Sep 24, 2006, at 7:29 PM, Andy Mabbett wrote:
> 
>> In message <C13C4877.7BB2E%tantekcs.stanford.edu>, Tantek Çelik
>> <tantekcs.stanford.edu> writes
>> 
>>> date
>> 
>> How about this as a model:
>> 
>>         "date" is an optional component
of the "currency" microformat.
>> 
>>         When date is present, parsers may disregard
it.
>> 
>>         When parsers understand date, and none is
present, they may
>>         infer the date from any containing element
(e.g. review, hAtom
>>         entry, hResume-hCalendar, etc.)
>> ?
> 
> the problem I see with logic like the above is the one
that comes up
> semi-frequently when trying to address issues like this
-- that a
> parser for X must then understand all other current
(and future)
> microformats in order to extract the proper meaning
from the markup.

This is fallacious argument.

Using a building block != using all building blocks.

In addition, the complexity/waste is far worse for the
alternative, that is
a set of silo formats with duplicated functionality rather
than using sets
of simple, small, modular formats together which is what
we're trying to do
with microformats.

In addition, there is another reason for keeping the
"dated" version of
currencies separate.

Solve a simpler problem first.

The problem of just representing a current currency value
(per the context)
is simpler than representing a currency value at a specific
date in history.

Another thought is that the space of "historical
data" is probably a more
relevant way to discuss this than just currency.  People
assert all kinds of
facts about the past (not just currency), and rather than
having something
that is specific to currency, perhaps this implies a need
for a simpler
"history" microformat which can then contain any
kind of data which is
asserted to be true/accurate as of that point in history.

Let's think modular here folks.

Thanks,

Tantek

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

In message <091FE9AD-D8AA-4D34-9362-095B6264D179placenamehere.com>,
Chris Casciano <chrisplacenamehere.com>
writes

>> How about this as a model:
>>
>>         "date" is an optional component
of the "currency" microformat.
>>
>>         When date is present, parsers may disregard
it.
>>
>>         When parsers understand date, and none is
present, they may
>>         infer the date from any containing element
(e.g. review, hAtom
>>         entry, hResume-hCalendar, etc.)
>> ?
>
>the problem I see with logic like the above is the one
that comes up
>semi-frequently when trying to address issues like this
-- that a
>parser for X must then understand all other current (and
future)
>microformats in order to extract the proper meaning from
the markup.

How so? And isn't there a proposed "microformat
object", or some such,
to allow for this?

>I would also worry about being too ambitious with
applying context
>clues (e.g. a blog post stating "i remember buying
a comic book for
>10˘" and then applying the post date to the value)
but that may be
>more of an authoring issue that could be worked through
with more
>discussion then my first concern.

Yes; that's a very good argument for allowing and using the
date
component properly, as proposed.

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

                Free Our Data:  <http://www.freeourd
ata.org.uk>
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss