Microformats Wiki - User contributions [en]

irc-people

2006-11-20T03:03:56Z

Lachlan Hunt:

A list of [[irc|IRC]] regulars and their normal timezones. (winter/summer)

* [[User:BenWest|bewest]] (-0800/-0700)
* [[User:Adam Craven|AdamCraven]] (+0000)
* [[User:Amette|amette]] (+1000)
* [[User:B.K._DeLong|bkdelong]] (-0500/-0400)
* [[User:Ben Ward|BenWard]] (+0000)
* [[User:BenjaminCarlyle|BenjaminCarlyle]] (+1000)
* [[User:Boneill|boneill]] (+0000)
* [[User:Brian|briansuda]] (+0000)
* [[User:ColinDDevroe|cdevroe]] (-0500/-0600)
* [[User:Cgriego|cgriego]] (-0600/-0500)
* [[User:CharlesRoper|charles_r]] (0000/+0100)
* [[User:ChrisCasciano|pnhChris]] (-0500/-0400)
* [[User:ChrisMessina|factoryjoe]] (-0800/-0700)
* [[User:ChristopherStJohn|cks]] (-0600/-0500)
* [[User:Cloud|Cloud]] (+0000)
* [[User:DanC|DanC]] (-0600/-0500)
** office hours: Wednesday afternoons, America/Chicago time
* [[User:DannyAyers|danja]] (+0100/+0200)
* [[User:Dave Cardwell|davecardwell]] (+0000)
* [[User:DeanEro|deanero]] (-0800/-0700)
* [[User:DimitriGlazkov|dglazkov]] (-0600/-0500)
* [[User:DrewMcLellan|drewinthehead]] (+0000/+0100)
* [[User:EdwardOConnor|hober]] (-0800/-0700)
* [[User:Enric|enric]] (-0800/-0700)
* [[User:Evan|evanpro]] (-0500)
* [[User:Fil|Fil]] (+0200)
* [[User:Grantbow|Grantbow]] (-0800/-0700)
* [[User:Hlb|hlb]] (+0800-0700)
* [[User:IanHickson|Hixie]] (-0800/-0700)
* [[User:Izo|IZO]]
* [[User:JoeGregorio|jcgregorio]]
* [[User:Jonathan_Arkell|jonnay]] (-0700/0600)
* [[User:JasonK|jkridner]]] (-0600/-0500)
* [[User:Kapowaz|kapowaz]] (+0000/+0100)
* [[User:Keri Henare|kerihenare]] (+1200)
* [http://epeus.blogspot.com/ KevinMarks] (-0800/-0700)
* [[User:Lachlan Hunt|Lachy]] (+1000/+1100)
* [[User:Mark Mansour|Mark Mansour]] (+1100)
* [[User:MarkNormanFrancis|Mark Norman Francis]] (+0000/+0100)
* [[User:CiaranMc|McNulty]] (+0000/+0100)
* [[User:neuro|neuro`]]
* [[User:Phae|Phae]] (+0000/+0100)
* [[User:PriitLaes|plaes]] (+0200/+0300)
* [[User:DavidOsolkowski|qid]] (-0500)
* [[User:Remi|Remi]] (-0500/-0400)
* [[User:RobertBachmann|RobertBachmann]] (+0100/+0200)
** Office hours: <del>Wednesday, 18:00-20:00 UTC</del> (Currently no office hours)
* [[User:Ronnos|Ron Kok]] (+0000)
* [[User:RyanKing|kingryan]] (-0800/-0700)
** [http://theryanking.com/blog/archives/2006/04/19/office-hours/ Office hours]: Wednesday, 21:00 UTC
* [[User:Csarven|csarven]] (-0500/-0400)
* [[User:Dana Benson|Snowden]] (-0800/-0700)
* [[User:Steve Ganz|SteveGanz]] (-0800/-0700)
* [[User:Tantek|Tantek]] (-0800/-0700)
* [[User:Trovster|trovster]] (-0800/-0700)
* [[User:Dan Kubb|dkubb]] (-0800/-0700)
* [[User:Ed Summers|edsu]] (-0500/-0400)
* [[User:Smackman|Steve Farrell]] (-0800/-0700)
* [[User:Enric|Enric]] (-0800/-0700)
* [[User:Charlvn|Charl]] (+0200/+0200)
* [[User:MarkoMrdjenovic|friedcell]] (+0100/+0200)
* [[User:Vant|vant]] (+0900)
* [[User:KrissWatt|VoodooChild]] (+0000/+0100)
* [[User:IwaiMasaharu|iwaim]] (+0900)
* [[User:Richard Conyard|WhiskeyM]] (+0000)
* [[User:Veeliam|William Lawrence]] (-0800/-0700)
* [[User:Ianloic|yakk]] (-0800/-0700)
* [[User:Ashley|Ashley]] (+1000)
* [[User:SuperPhly|SuperPhly]] (-600/-500)
* [[User:Colin_Barrett|cbarrett]] (-1000)
* [[User:HenriBergius|bergie]] (+0200/+0300)
* [[User:JacksonWilkinson|whafro]] (-0500/-0400)
* [[User:Adactio|Jeremy Keith]] (+0000)
* [[User:JulianStahnke|Julian Stahnke]] (+0000)

hcard-feedback

2006-11-19T16:04:45Z

Lachlan Hunt: Typo

<h1> hCard feedback </h1>

General feedback about [[hcard|hCard]] may be provided here, and the editor(s) will do their best to try to accomodate such feedback. The more specific the feedback the better chance it will be handled. For specific issues with the spec (as opposed to general problems and feedback), please use the [[hcard-issues|hCard issues]] page.

Feedback may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Use the provided template and add your feedback to the end of the Feedback section. Write your feedback well. — [http://tantek.com/log/ Tantek]

__TOC__

== Feedback ==

* 2006-11-15 raised by [http://lachy.id.au/ Lachy] in [irc://freenode/whatwg #whatwg] (an IRC channel on [http://freenode.net/ freenode] about [http://whatwg.org/ The WHATWG]).
*# ''I think the whole [[hcard|hCard]] specification needs to be restructured.''
*# ''It's incredibly difficult to work out what each class name means and how to use them properly.''

* 2006-11-15 raised by hsivonen in #whatwg.
*# ''Without knowing iCalendar or vCard, it is totally non-obvious to see what hCards or hCalendars would be conforming. The normative part is extremely short and doesn't seem to establish clear enough a mapping between the microformats and the RFCs.''
*#* This (and Lachy's 2nd feedback point above) should be addressed by clarifying the mapping with better use of the [[hcard-profile|hCard profile]] which does clearly map the class names to vCard properties and the sections of the vCard specification that defines them. - Tantek

* 2006-11-15 raised by Hixie in #whatwg (and agreed by [http://lachy.id.au/ Lachy] and hsivonen).
*# ''The [[hcard|hCard]] spec basically reads as a brainstorm, not a normative spec.''

* 2006-11-17 raised by [http://lachy.id.au/ Lachlan Hunt].
*# Semantic XHTML Design Princples: This section should go. Guidelines for how to write a microformats specification do not belong in the spec itself.
*# Format - More Semantic Equivalents: Explanations of how to use each property correctly should be given with each and every property, not just list a few at the top before the properties have even been defined.
*# Singlular vs. Plural: It is unclear what is meant by singular vs. plural properties. Ordinarily, a plural is word that refers to multiple objects, but in this spec, it's being used to designate a property that can be used more than once. It doesn't make sense because the property itself isn't a plural. Besides, this section should go. The number of times a property can be used should be listed with each individual property description.
*# Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.
*# Human vs. Machine Readable: This title only makes some sense for the use of the abbr element. Everything in this section should be moved to a Conformance Requirements section, which explains how to extract values from the markup. It should also use RFC 2119 terminology that describes exactly what a UA has to do. Presently, it's written to informatively, rather than normatively (particularly for the abbr element).
*# Property List: This section is almost useless, it's effectively written like an index of properties but doesn't link to or help define, in any way whatsoever, what the actual meaning of a property is, nor how to use it. For every single property, all of the following information should be listed
*#* Property name
*#* Expansion (e.g. it's not clear from this section what fn stands for. First Name? Family Name? Full Name? Flight Number?)
*#* Definition. (e.g. either copy the definition directly from vCard or provide a short summary, and also a link to the relevant vCard section. Saying just "See section #.#.# of RFC 2426.", as done in the profile, is not so easy to do.)
*#* Usage
*#** Contexts in which this property may be used
*#** Content model (e.g. list of sub properties, expected elements, text, or whatever)
*#** Syntax of the value (i.e. plain text, number, URI, etc.)
*#** Elements this property may be used on
*#* How to interpret the value (may link to relevant section in Conformance Requirements)
**I second all of the above. [[User:AndyMabbett|Andy Mabbett]] 07:15, 17 Nov 2006 (PST)

== Template ==

Please use this format (copy and paste this to the end of the list to add your feedback):
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Here is the first general feedback I have.''
*# ''Here is the second general feedback I have.''

hcard-feedback

2006-11-19T07:04:29Z

Lachlan Hunt: #whatwg on freenode

<h1> hCard feedback </h1>

General feedback about [[hcard|hCard]] may be provided here, and the editor(s) will do their best to try to accomodate such feedback. The more specific the feedback the better chance it will be handled. For specific issues with the spec (as opposed to general problems and feedback), please use the [[hcard-issues|hCard issues]] page.

Feedback may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Use the provided template and add your feedback to the end of the Feedback section. Write your feedback well. — [http://tantek.com/log/ Tantek]

__TOC__

== Feedback ==

* 2006-11-15 raised by [http://lachy.id.au/ Lachy] in [irc://freenode/whatwg #whatwg].
*# ''I think the whole [[hcard|hCard]] specification needs to be restructured.''
*# ''It's incredibly difficult to work out what each class name means and how to use them properly.''

* 2006-11-15 raised by hsivonen in #whatwg.
*# ''Without knowing iCalendar or vCard, it is totally non-obvious to see what hCards or hCalendars would be conforming. The normative part is extremely short and doesn't seem to establish clear enough a mapping between the microformats and the RFCs.''
*#* This (and Lachy's 2nd feedback point above) should be addressed by clarifying the mapping with better use of the [[hcard-profile|hCard profile]] which does clearly map the class names to vCard properties and the sections of the vCard specification that defines them. - Tantek

* 2006-11-15 raised by Hixie in #whatwg (and agreed by [http://lachy.id.au/ Lachy] and hsivonen).
*# ''The [[hcard|hCard]] spec basically reads as a brainstorm, not a normative spec.''

* 2006-11-17 raised by [http://lachy.id.au/ Lachlan Hunt].
*# Semantic XHTML Design Princples: This section should go. Guidelines for how to write a microformats specification do not belong in the spec itself.
*# Format - More Semantic Equivalents: Explanations of how to use each property correctly should be given with each and every property, not just list a few at the top before the properties have even been defined.
*# Singlular vs. Plural: It is unlear what is meant by singular vs. plural properties. Ordinarily, a plural is word that refers to multiple objects, but in this spec, it's being used to designate a property that can be used more than once. It doesn't make sense because the property itself isn't a plural. Besides, this section should go. The number of times a property can be used should be listed with each individual property description.
*# Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.
*# Human vs. Machine Readable: This title only makes some sense for the use of the abbr element. Everything in this section should be moved to a Conformance Requirements section, which explains how to extract values from the markup. It should also use RFC 2119 terminology that describes exactly what a UA has to do. Presently, it's written to informatively, rather than normatively (particularly for the abbr element).
*# Property List: This section is almost useless, it's effectively written like an index of properties but doesn't link to or help define, in any way whatsoever, what the actual meaning of a property is, nor how to use it. For every single property, all of the following information should be listed
*#* Property name
*#* Expansion (e.g. it's not clear from this section what fn stands for. First Name? Family Name? Full Name? Flight Number?)
*#* Definition. (e.g. either copy the definition directly from vCard or provide a short summary, and also a link to the relevant vCard section. Saying just "See section #.#.# of RFC 2426.", as done in the profile, is not so easy to do.)
*#* Usage
*#** Contexts in which this property may be used
*#** Content model (e.g. list of sub properties, expected elements, text, or whatever)
*#** Syntax of the value (i.e. plain text, number, URI, etc.)
*#** Elements this property may be used on
*#* How to interpret the value (may link to relevant section in Conformance Requirements)

**I second all of the above. [[User:AndyMabbett|Andy Mabbett]] 07:15, 17 Nov 2006 (PST)

==Meta==
(feel free to remove once dealt with)
*A definition of, or link to, "#whatwg" would be useful. [[User:AndyMabbett|Andy Mabbett]] 06:37, 16 Nov 2006 (PST)
** #whatwg is an IRC channel on Freenode.
***What's it about? What's "Freenode"? Why assume that a novice user of uFs knows these things? [[User:AndyMabbett|Andy Mabbett]] 07:15, 17 Nov 2006 (PST)
**** Where it came from is not really all that relevant, it doesn't matter that much if someone doesn't know what the channel is about. But it's an IRC channel on [http://freenode.net/ freenode] about [http://whatwg.org/ The WHATWG]. --[[User:Lachlan Hunt|Lachlan Hunt]] 23:04, 18 Nov 2006 (PST)

== Template ==

Please use this format (copy and paste this to the end of the list to add your feedback):
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Here is the first general feedback I have.''
*# ''Here is the second general feedback I have.''

hcard-feedback

2006-11-17T05:02:16Z

Lachlan Hunt: /* Feedback */ Corrected list bullets

<h1> hCard feedback </h1>

General feedback about [[hcard|hCard]] may be provided here, and the editor(s) will do their best to try to accomodate such feedback. The more specific the feedback the better chance it will be handled. For specific issues with the spec (as opposed to general problems and feedback), please use the [[hcard-issues|hCard issues]] page.

Feedback may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Use the provided template and add your feedback to the end of the Feedback section. Write your feedback well. — [http://tantek.com/log/ Tantek]

__TOC__

== Feedback ==

* 2006-11-15 raised by [http://lachy.id.au/ Lachy] in #whatwg.
*# ''I think the whole [[hcard|hCard]] specification needs to be restructured.''
*# ''It's incredibly difficult to work out what each class name means and how to use them properly.''

* 2006-11-15 raised by hsivonen in #whatwg.
*# ''Without knowing iCalendar or vCard, it is totally non-obvious to see what hCards or hCalendars would be conforming. The normative part is extremely short and doesn't seem to establish clear enough a mapping between the microformats and the RFCs.''
*#* This (and Lachy's 2nd feedback point above) should be addressed by clarifying the mapping with better use of the [[hcard-profile|hCard profile]] which does clearly map the class names to vCard properties and the sections of the vCard specification that defines them. - Tantek

* 2006-11-15 raised by Hixie in #whatwg (and agreed by [http://lachy.id.au/ Lachy] and hsivonen).
*# ''The [[hcard|hCard]] spec basically reads as a brainstorm, not a normative spec.''

* 2006-11-17 raised by [http://lachy.id.au/ Lachlan Hunt].
*# Semantic XHTML Design Princples: This section should go. Guidelines for how to write a microformats specification do not belong in the spec itself.
*# Format - More Semantic Equivalents: Explanations of how to use each property correctly should be given with each and every property, not just list a few at the top before the properties have even been defined.
*# Singlular vs. Plural: It is unlear what is meant by singular vs. plural properties. Ordinarily, a plural is word that refers to multiple objects, but in this spec, it's being used to designate a property that can be used more than once. It doesn't make sense because the property itself isn't a plural. Besides, this section should go. The number of times a property can be used should be listed with each individual property description.
*# Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.
*# Human vs. Machine Readable: This title only makes some sense for the use of the abbr element. Everything in this section should be moved to a Conformance Requirements section, which explains how to extract values from the markup. It should also use RFC 2119 terminology that describes exactly what a UA has to do. Presently, it's written to informatively, rather than normatively (particularly for the abbr element).
*# Property List: This section is almost useless, it's effectively written like an index of properties but doesn't link to or help define, in any way whatsoever, what the actual meaning of a property is, nor how to use it. For every single property, all of the following information should be listed
*#* Property name
*#* Expansion (e.g. it's not clear from this section what fn stands for. First Name? Family Name? Full Name? Flight Number?)
*#* Definition. (e.g. either copy the definition directly from vCard or provde a short summary, and also a link to the relevant vCard section. Saying just "See section #.#.# of RFC 2426.", as done in the profile, is not so easy to do.)
*#* Usage
*#** Contexts in which this property may be used
*#** Content model (e.g. list of sub properties, expected elements, text, or whatever)
*#** Syntax of the value (i.e. plain text, number, URI, etc.)
*#** Elements this property may be used on
*#* How to interpret the value (may link to relevant section in Conformance Requirements)

==Meta==
(feel free to remove once dealt with)
*A definition of, or link to, "#whatwg" would be useful. [[User:AndyMabbett|Andy Mabbett]] 06:37, 16 Nov 2006 (PST)
** #whatwg is an IRC channel on Freenode.

== Template ==

Please use this format (copy and paste this to the end of the list to add your feedback):
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Here is the first general feedback I have.''
*# ''Here is the second general feedback I have.''

hcard-feedback

2006-11-17T05:01:21Z

Lachlan Hunt: Added more feedback

<h1> hCard feedback </h1>

General feedback about [[hcard|hCard]] may be provided here, and the editor(s) will do their best to try to accomodate such feedback. The more specific the feedback the better chance it will be handled. For specific issues with the spec (as opposed to general problems and feedback), please use the [[hcard-issues|hCard issues]] page.

Feedback may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Use the provided template and add your feedback to the end of the Feedback section. Write your feedback well. — [http://tantek.com/log/ Tantek]

__TOC__

== Feedback ==

* 2006-11-15 raised by [http://lachy.id.au/ Lachy] in #whatwg.
*# ''I think the whole [[hcard|hCard]] specification needs to be restructured.''
*# ''It's incredibly difficult to work out what each class name means and how to use them properly.''

* 2006-11-15 raised by hsivonen in #whatwg.
*# ''Without knowing iCalendar or vCard, it is totally non-obvious to see what hCards or hCalendars would be conforming. The normative part is extremely short and doesn't seem to establish clear enough a mapping between the microformats and the RFCs.''
*#* This (and Lachy's 2nd feedback point above) should be addressed by clarifying the mapping with better use of the [[hcard-profile|hCard profile]] which does clearly map the class names to vCard properties and the sections of the vCard specification that defines them. - Tantek

* 2006-11-15 raised by Hixie in #whatwg (and agreed by [http://lachy.id.au/ Lachy] and hsivonen).
*# ''The [[hcard|hCard]] spec basically reads as a brainstorm, not a normative spec.''

* 2006-11-17 raised by [http://lachy.id.au/ Lachlan Hunt].
*# Semantic XHTML Design Princples: This section should go. Guidelines for how to write a microformats specification do not belong in the spec itself.
*# Format - More Semantic Equivalents: Explanations of how to use each property correctly should be given with each and every property, not just list a few at the top before the properties have even been defined.
# Singlular vs. Plural: It is unlear what is meant by singular vs. plural properties. Ordinarily, a plural is word that refers to multiple objects, but in this spec, it's being used to designate a property that can be used more than once. It doesn't make sense because the property itself isn't a plural. Besides, this section should go. The number of times a property can be used should be listed with each individual property description.
*# Plural Properties Singularized: What the...? After attempting to read that paragraph several times, I still can't comprehend what on earth it's trying to say.
*# Human vs. Machine Readable: This title only makes some sense for the use of the abbr element. Everything in this section should be moved to a Conformance Requirements section, which explains how to extract values from the markup. It should also use RFC 2119 terminology that describes exactly what a UA has to do. Presently, it's written to informatively, rather than normatively (particularly for the abbr element).
*# Property List: This section is almost useless, it's effectively written like an index of properties but doesn't link to or help define, in any way whatsoever, what the actual meaning of a property is, nor how to use it. For every single property, all of the following information should be listed
*#* Property name
*#* Expansion (e.g. it's not clear from this section what fn stands for. First Name? Family Name? Full Name? Flight Number?)
*#* Definition. (e.g. either copy the definition directly from vCard or provde a short summary, and also a link to the relevant vCard section. Saying just "See section #.#.# of RFC 2426.", as done in the profile, is not so easy to do.)
*#* Usage
*#** Contexts in which this property may be used
*#** Content model (e.g. list of sub properties, expected elements, text, or whatever)
*#** Syntax of the value (i.e. plain text, number, URI, etc.)
*#** Elements this property may be used on
*#* How to interpret the value (may link to relevant section in Conformance Requirements)

==Meta==
(feel free to remove once dealt with)
*A definition of, or link to, "#whatwg" would be useful. [[User:AndyMabbett|Andy Mabbett]] 06:37, 16 Nov 2006 (PST)
** #whatwg is an IRC channel on Freenode.

== Template ==

Please use this format (copy and paste this to the end of the list to add your feedback):
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Here is the first general feedback I have.''
*# ''Here is the second general feedback I have.''

mailing-lists-proposals

2006-10-25T05:18:54Z

Lachlan Hunt: Added -wg and -tf proposals

There is a proposal for creating a new mailing list for discussing the research and creation of new microformats so that those discussions do not overwhelm microformats-discuss.

Some candidates for names with the thinking behind them. Feel free to add your name and opinion (+/- 1 or 0).

* microformats-new (focusing on discussing "new" microformats)
** +1 tantek
** +1 ScottReynen
** -1 Lachlan Hunt
** +1 Joe Andrieu
** -1 Andy Mabbett
** +1 Bob Jonkman
** +1 Ben Ward
** +1 Ben O'Neill
* microformats-research (focusing on the essential, and often overlooked by first-time proposers "research" phase(s) in the process)
** +1 tantek
** +1 ScottReynen
** +1 cgriego
** +1 Phae
** +1 JustinThorp
** -1 Andy Mabbett
** -1 Joe Andrieu
** -1 Bob Jonkman (research is part of process, best documented on the Wiki)
** -1 Ben Ward (strikes me as dilution too far of µf-discuss and µf-new)
** 0 Lachlan Hunt
* microformats-process (That's really what we're talking about with research of new microformats, isn't it?)
** +1 ScottReynen
** +1 Lachlan Hunt
** +1 [[User:Singpolyma|singpolyma]]
** -1 Andy Mabbett
** -1 Joe Andrieu
** -1 cgriego (reminds me of parsing--processing--more so than even microformats-dev)
** -1 Bob Jonkman (Is this the process of creating a new microformat, or the some other process? Document it on the Wiki, I say)
* microformats-propose (it misses the point of the process, and implies that there is a desire for microformats proposals - there isn't)
** -1 tantek
** -1 ScottReynen
** 0 Andy Mabbett
** -1 Bob Jonkman
** -1 Ben Ward
* microformats-suggest (similar to propose but milder ;)
** +1 ChrisMessina
** 0 tantek
** -1 ScottReynen
** -1 Phae (I feel this is just -propose in disguise)
** -1 BenWest
** -1 Andy Mabbett
** -1 Bob Jonkman
** -1 Ben Ward (If µf-new or similar is created for active spec'ing and format development, uf-discuss would comfortably accomodate this as part of the course of discussion)
* microformats-work: For working on microformats, new and old.
** +1 BenWest: I thought we are interested in a list that provides a venue for iterating through the process, and revising and refining microformats in general. discuss is for newbies, and dev is for implementing them.
* nothing (fix uf-dev, do nothing else (for now))
** +1 RyanKing
** +1 Tim White
** +1 Andy Mabbett
** 0 Bob Jonkman
** 0 Ben Ward
** -1 BenWest
** -1 Tantek (we have opened uf-dev and I still strongly believe we need a new list for the discussion of new microformats, separate from microformats-discuss in order to avoid overwhelming new folks with details and minutiae of new and in development formats.)
* microformats-wg (abbreviation of Working Group)
** +1 Lachlan Hunt
* microformats-tf (abbreviation of Task Force)
** 0 Lachlan Hunt

==Comment==

===Andy Mabbett===
Why not create a new mailing list for each proposal, once it's reached a certain stage? Then , if the uF is created, or the proposal abandoned, the specific list would be closed, and the archive retained as a link from the "brainstorming" page, as a permanent, and discrete record of discussion on that topic.

Alternatively, the list could be retained for discussion of the implementation and development of that specific uF.

For example, several academic and professional taxonomists have told me in e-mail that they would be interested in the [[species]] proposal, (and one astronomer, likewise, for [[mars]]/ [[luna]]), but do not have the time to follow a general mailing list; indeed, a couple asked me specifically if I would set up a separate mailing list for the subject.

[[User:AndyMabbett|Andy Mabbett]] 04:44, 24 Oct 2006 (PDT)

mailing-lists-proposals

2006-10-25T05:04:18Z

Lachlan Hunt: Corrected my votes

There is a proposal for creating a new mailing list for discussing the research and creation of new microformats so that those discussions do not overwhelm microformats-discuss.

Some candidates for names with the thinking behind them. Feel free to add your name and opinion (+/- 1 or 0).

* microformats-new (focusing on discussing "new" microformats)
** +1 tantek
** +1 ScottReynen
** -1 Lachlan Hunt
** +1 Joe Andrieu
** -1 Andy Mabbett
** +1 Bob Jonkman
** +1 Ben Ward
** +1 Ben O'Neill
* microformats-research (focusing on the essential, and often overlooked by first-time proposers "research" phase(s) in the process)
** +1 tantek
** +1 ScottReynen
** +1 cgriego
** +1 Phae
** +1 JustinThorp
** -1 Andy Mabbett
** -1 Joe Andrieu
** -1 Bob Jonkman (research is part of process, best documented on the Wiki)
** -1 Ben Ward (strikes me as dilution too far of µf-discuss and µf-new)
** 0 Lachlan Hunt
* microformats-process (That's really what we're talking about with research of new microformats, isn't it?)
** +1 ScottReynen
** +1 Lachlan Hunt
** +1 [[User:Singpolyma|singpolyma]]
** -1 Andy Mabbett
** -1 Joe Andrieu
** -1 cgriego (reminds me of parsing--processing--more so than even microformats-dev)
** -1 Bob Jonkman (Is this the process of creating a new microformat, or the some other process? Document it on the Wiki, I say)
* microformats-propose (it misses the point of the process, and implies that there is a desire for microformats proposals - there isn't)
** -1 tantek
** -1 ScottReynen
** 0 Andy Mabbett
** -1 Bob Jonkman
** -1 Ben Ward
* microformats-suggest (similar to propose but milder ;)
** +1 ChrisMessina
** 0 tantek
** -1 ScottReynen
** -1 Phae (I feel this is just -propose in disguise)
** -1 BenWest
** -1 Andy Mabbett
** -1 Bob Jonkman
** -1 Ben Ward (If µf-new or similar is created for active spec'ing and format development, uf-discuss would comfortably accomodate this as part of the course of discussion)
* microformats-work: For working on microformats, new and old.
** +1 BenWest: I thought we are interested in a list that provides a venue for iterating through the process, and revising and refining microformats in general. discuss is for newbies, and dev is for implementing them.
* nothing (fix uf-dev, do nothing else (for now))
** +1 RyanKing
** +1 Tim White
** +1 Andy Mabbett
** 0 Bob Jonkman
** 0 Ben Ward
** -1 BenWest
** -1 Tantek (we have opened uf-dev and I still strongly believe we need a new list for the discussion of new microformats, separate from microformats-discuss in order to avoid overwhelming new folks with details and minutiae of new and in development formats.)

==Comment==

===Andy Mabbett===
Why not create a new mailing list for each proposal, once it's reached a certain stage? Then , if the uF is created, or the proposal abandoned, the specific list would be closed, and the archive retained as a link from the "brainstorming" page, as a permanent, and discrete record of discussion on that topic.

Alternatively, the list could be retained for discussion of the implementation and development of that specific uF.

For example, several academic and professional taxonomists have told me in e-mail that they would be interested in the [[species]] proposal, (and one astronomer, likewise, for [[mars]]/ [[luna]]), but do not have the time to follow a general mailing list; indeed, a couple asked me specifically if I would set up a separate mailing list for the subject.

[[User:AndyMabbett|Andy Mabbett]] 04:44, 24 Oct 2006 (PDT)

user-profile-examples

2006-10-02T10:19:22Z

Lachlan Hunt: /* Contributors */

<h1> profile examples </h1>

Examples of how user profiles are marked up currently, with the idea of moving towards a microformat for marking up user profiles that are posted on the Web. Next steps are documenting [[profile-formats]], and doing some [[profile-brainstorming]].

The potential profile microformat would of course need to build upon hcard.

__TOC__

== Contributors ==
* [http://factoryjoe.com/blog Chris Messina]
* [http://abstractioneer.org John Panzer]
* [http://lachy.id.au/ Lachlan Hunt]

== Examples in the Wild ==

=== Flickr ===

=== Upcoming.org ===

=== MySpace ===

=== OpenBC ===

=== AIMPages ===

=== LinkedIn ===

=== LavaLife ===
* http://www.lavalife.com/
* http://www.lavalife.ca/en
* http://www.lavalife.ca/fr
* http://www.lavalife.com.au/

=== RSVP ===
* http://rsvp.com.au/

=== AdultMatchMaker ===
* http://adultmatchmaker.com.au/

=== Match.com ===
* http://match.com/
* http://match.com.au/

=== When2Date ===
* http://when2date.com/

=== Other Non English Sites ===
* http://fr.meetic.yahoo.net/ - French
* http://partner.yahoo.co.jp/ - Japanese
* http://cn.personals.yahoo.com/ - Chinese

user-profile-examples

2006-10-02T10:18:23Z

Lachlan Hunt: /* Examples in the Wild */ Added When2Date

<h1> profile examples </h1>

Examples of how user profiles are marked up currently, with the idea of moving towards a microformat for marking up user profiles that are posted on the Web. Next steps are documenting [[profile-formats]], and doing some [[profile-brainstorming]].

The potential profile microformat would of course need to build upon hcard.

__TOC__

== Contributors ==
* [http://factoryjoe.com/blog Chris Messina]
* [http://abstractioneer.org John Panzer]

== Examples in the Wild ==

=== Flickr ===

=== Upcoming.org ===

=== MySpace ===

=== OpenBC ===

=== AIMPages ===

=== LinkedIn ===

=== LavaLife ===
* http://www.lavalife.com/
* http://www.lavalife.ca/en
* http://www.lavalife.ca/fr
* http://www.lavalife.com.au/

=== RSVP ===
* http://rsvp.com.au/

=== AdultMatchMaker ===
* http://adultmatchmaker.com.au/

=== Match.com ===
* http://match.com/
* http://match.com.au/

=== When2Date ===
* http://when2date.com/

=== Other Non English Sites ===
* http://fr.meetic.yahoo.net/ - French
* http://partner.yahoo.co.jp/ - Japanese
* http://cn.personals.yahoo.com/ - Chinese

user-profile-examples

2006-10-02T04:47:43Z

Lachlan Hunt: /* Examples in the Wild */

<h1> profile examples </h1>

Examples of how user profiles are marked up currently, with the idea of moving towards a microformat for marking up user profiles that are posted on the Web. Next steps are documenting [[profile-formats]], and doing some [[profile-brainstorming]].

The potential profile microformat would of course need to build upon hcard.

__TOC__

== Contributors ==
* [http://factoryjoe.com/blog Chris Messina]
* [http://abstractioneer.org John Panzer]

== Examples in the Wild ==

=== Flickr ===

=== Upcoming.org ===

=== MySpace ===

=== OpenBC ===

=== AIMPages ===

=== LinkedIn ===

=== LavaLife ===
* http://www.lavalife.com/
* http://www.lavalife.ca/en
* http://www.lavalife.ca/fr
* http://www.lavalife.com.au/

=== RSVP ===
* http://rsvp.com.au/

=== AdultMatchMaker ===
* http://adultmatchmaker.com.au/

=== Match.com ===
* http://match.com/
* http://match.com.au/

=== Other Non English Sites ===
* http://fr.meetic.yahoo.net/ - French
* http://partner.yahoo.co.jp/ - Japanese
* http://cn.personals.yahoo.com/ - Chinese

currency-formats

2006-10-02T01:45:50Z

Lachlan Hunt: /* XBRL */ Fixed URI for XBRL site.

= Currency formats prior art =

This page gathers information about existing practices and standards for representing currencies and currency-qualified numbers/amounts.

==Formats==

===XBRL===

[http://www.xbrl.org XBRL] is an XML-based business reporting language.

In XBRL, a currency is just another simple unit of measure.

In XBRL, a unit of measure can be simple or complex. A simple unit of measure if for instance "feet" while a complex unit of measure is "Euros per share".

Units of measurement can be specified anywhere in the XBRL document and assigned a unique identifier, then referred to from numerical facts.

The following examples show adapted versions of the [http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2005-11-07.htm#_example_20 XML examples].

In the adaptation, we have dropped the distinction that XBRL makes between the concept of "unit" and the concept of "measure". We only kept the notion of "unit", allowing a content fragment of class "unit" to contain other fragments of class "unit" to allow the definition of a complex unit.

Currency, UK Pounds.

<pre>
<span id="u1" class="unit">GBP</span>
</pre>

Square feet (as simple unit)

<pre>
<span id="u2" class="unit">sqrft</span>
</pre>

Square feet (as complex unit)

<pre>
<span id="u3" class="unit"><span class="unit">sqrft</span>*<span class="unit">sqrft</span></span>
</pre>

Earnings per share (EPS) measured in Euros per share.

<pre>
<span id="u4" class="unit"><span class="unit">EUR</span><span class="divide">/</span><span class="unit">shares</span></span>
</pre>

100 UK pounds (with referred-to unit)

<pre>
<span class="price">100<a href="#u1" rel="unit"/></span>
</pre>

100 UK pounds (with locally defined unit)

<pre>
<span class="price">100 <span id="u1" class="unit">GBP</span></span>
</pre>

===ISO 4217===

[http://www.iso.org/iso/en/prods-services/popstds/currencycodeslist.html ISO 4217], [http://en.wikipedia.org/wiki/ISO_4217] is an international standard for 3-letter currency codes.

===Interactive Financial Exchange (IFX) ===

The [http://www.ifxforum.org IFX Forum] develops a robust framework for the electronic business-to-business exchange of data among financial service institutions around the world".

Altough adapted to XML implementations, the IFX data model has been designed independently of XML technologies, so that it can be implemented using other representations than XML.

IFX defines the concept of a currency amount (CurAmt), which contains:
:an amount (Amt), which is a decimal value
:a currency code (CurCode), which is a 3-letter value defined in ISO-4217

===OFX===

The [http://www.ofx.net Open Financial Exchange] is a standard developed by Microsoft and Quicken for personal finance managers. They use the following conventions for currencies and currency values.

They have the concept of a default currency ("CURDEF"), which is a 3-letter ISO-4217 value.

Then they have the concept of the currency that a value is expressed in ("CURRENCY"), again with a 3-letter ISO-4217.

Last, there is also an option to provide an original currency, if the value has been converted. The ORIGCURRENCY contains a CURSYM (in ISO-4217) and a CURRATE, ratio of CURDEF to CURSYM.

===Canadian dollar===

Although the representation of a canadian dollar according to ISO-4217 is CAD, the most common representation of the currency according to some is CDN.

According to wikipedia:

<blockquote>There are various common abbreviations to distinguish the Canadian dollar from others: while the ISO currency code CAD (a three-character code without monetary symbols) is common, no single system is universally accepted. C$ is recommended by the Canadian government (e.g., per The Canadian Style guide) and is used by the International Monetary Fund, while Editing Canadian English indicates Can$ and CDN$; both guides note the ISO scheme/code. The abbreviation CA$ is also used, e.g., in some software packages.</blockquote>

::Any of which can be marked up thus: <nowiki><abbr class="currency" title="CAD">C$</abbr></nowiki> (or whatever "class" we eventually decide on) since any of them is a "symbol" representing CAD. - Andy Mabbett

===Other===

Other standards exist for specific currencies.

==See also==

* [[currency]]
* [[currency-examples]]
* [[currency-brainstorming]]