Microformats Wiki - User contributions [en]

rest/opacity

2006-11-19T22:44:33Z

MikeSchinkel: /* See Also */ Added questions for Ernie's writings

''(Adapted from a post by RESTfather [http://roy.gbiv.com/ Roy Fielding] on [http://groups.yahoo.com/group/rest-discuss/message/5369 rest-discuss]; used by permission. The context was a discussion about what Tim Berners-Lee meant by his so-called 'Opacity Axiom', specifically how it applies to REST.)''

= Roy on Opacity in REST =

== Historical Context ==
...In order to understand TimBL's design notes, you have to know about the context in which
he is writing a response. In this case, various thoughts were
recorded as the "Opacity Axiom" in response to a discussion about
client behavior and the perceived need for URNs. It has long
since been taken out of context and abused in various ways.

Also, keep in mind that TimBL's design note was written two
years after Henrik and I [Roy Fielding] worked out the important bits of what
would become the HTTP object model, later re-named REST to get
away from OOM terms, about 18 months after we had similar
discussions at MIT with TimBL and the rest of the W3C team, and
more than a year after HTTP/1.0 was finished and HTTP/1.1 proposed.
So, saying it was something that I "didn't really care to
integrate so much" is missing the mark by quite a bit -- he is
trying to describe our model to people who did not understand it.

== Original Intent ==

The opacity principle, as actually used on the Web, refers only
to the machine interpretation of request processing as being
dependent on control data (e.g., hypertext anchors and message
field names) rather than on metadata appearing within the URI.
It is the same reason why we distinguish media types from data
formats -- the fact that a string of bytes looks like angle tags
doesn't mean we want to process it as HTML. Ignoring any
semantically significant data in a URI allows operations on a
resource to be orthogonal to identification of the resource.

REST does include the opacity axiom in the original sense of
that phrase. I did not use it by name in REST because it isn't
a principle at all -- opacity is just a name TimBL used for the
set of constraints around URI processing by clients (a byproduct
of the constraints that you will find in REST). The principle
involved is orthogonal design.

== Applicability to Clients ==

"Opacity of URI" only applies to clients and, even then, only to
those parts of the URI that are not defined by relevant standards.
Origin servers, for example, have the choice of interpreting a
URI as being opaque or as a structure that defines how the server
maps the URI to a representation of the resource. Cool URIs will
often make a transition from being originally interpreted as
structure by the server and then later treated as an opaque
string (perhaps because the server implementation has changed
and the owner wants the old URI to persist). The server can make
that transition because clients are required to act like they
are ignorant of the server-private structure.

Clients are allowed to treat a URI as being structured
if that structure is defined by standard (e.g., scheme and
authority in "http") or if the server tells the client how its
URI is structured. For example, both GET-based FORM actions and
server-side image map processing compose the URI from a
server-provided base and a user-supplied suffix constructed
according to an algorithm defined by a standard media type.

== The Bottom Line ==

Note, however, that some people have taken the mere title of
"opacity" and assumed that it meant URIs should not have
meaningful construction at all. TimBL's axiom doesn't say
that and neither does REST.

= Summary by Jon Hanna =
(extracted from the microformats-rest mailing list; headers added later)

== Opacity Option ==

I think it's important that URIs *can* be treated opaquely - you can
link to them, you can cache their resources without processing them
beyond naive string-matching, process RDF graphs again without
processing them beyond naive string-matching, and so on.

== Non-Opacity Option ==

This does not preclude the fact that agents *may* construct or parse
URIs in more sophisticated ways, it just means that agents don't have
to, especially in the case of agents that are not aware of the specific
purpose of the application.

= Further Clarification by Roy =

== Not Quite ==

Er, not quite. The key is that the '''server''' is free to tell the client
that there does exist structure in a given URI-space, and then the
client is free to make use of ''that'' knowledge in future requests.
That is how server-side imagemaps worked -- HTML says that the src
URI is structured such that appending "?X,Y" to that URI, where
X and Y are non-negative integers, corresponds to points on a map
that can respond to future GET requests.

Thus, one way for the server to tell the client that a given URI
is structured is to provide the URI in a standard element of a
standard media type that has been defined as such. Another is to
include the URI in a response header field.

== Caveat to the Caveat ==

Note, however, that I am also one of the creators of the robots.txt
standard. That particular scenario requires that the spider find out
the constraints on a site prior to the very first access of a real
hypertext link. It is too late to obtain that information by
looking at header fields after a normal request is made. Adding a
new method to HTTP was out of the question because it would have
to be deployed before it could be used
''[OPTIONS could fulfill that purpose today, 12 years after robots.txt was defined]''.
Adding fields to DNS wasn't an option back then, either. Reserving /robots.txt
remains the best option given the alternatives available.

Note, however, that no other "reserved URI" features have the same
requirements as spiders, so it is still true that favicon and pics
chose the wrong solution.

= Final Comment By Dr. Ernie Prabhakar =

This implies to me that the ''server'' could use a specific microformat to indicate that a given URL can be treated in a particular way. In the absence of a such a microformat, clients should not make any such assumptions; further, servers should avoid requiring clients to understand that microformat in order to receive service.

= See Also =

The treatment of URI opacity on the RestWiki. http://rest.blueoxen.net/cgi-bin/wiki.pl?RestAndUriOpacity]

=Questions by Mike Schinkel=
1.) Ernie, you state the following:
<blockquote>''Cool URIs will often make a transition from being originally interpreted as structure by the server and then later treated as an opaque string (perhaps because the server implementation has changed and the owner wants the old URI to persist). The server can make that transition because clients are required to act like they are ignorant of the server-private structure.''</blockquote>
This doesn't quite sit right with me for some reason. Doesn't "opacity" refer to how a client sees the URI, not how a server sees it? To the server, nothing is/needs to be opaque, right? As such the change from a file/directory to a virtual reference inside the server configuration should have absolutely no relevence to the client and no relevence to the fact that the server/authority might have previously defined the URI structure for specific processing by a client. In the later case a change in server implementation should be totally invisible to any given client. Right?

2.) Additionally, you state:

<blockquote>''This implies to me that the server could use a specific microformat to indicate that a given URL can be treated in a particular way. In the absence of a such a microformat, clients should not make any such assumptions; further, servers should avoid requiring clients to understand that microformat in order to receive service. ''</blockquote>

Can you give an example of such a Microformat? Does one exist, or is it hypothetical on your part? Also, wouldn't such a "Microformat" be, almost by definition, non-visible and thus according to community concensus not a Microformat? (more of a "Microdirective", if you will. :)

Thanks in advance for the clafifications.

[[User:MikeSchinkel|MikeSchinkel]] 14:44, 19 Nov 2006 (PST)

rest/opacity

2006-10-25T19:29:26Z

MikeSchinkel: /* Final Comment By Ernie */ included Ernie's full name

''(Adapted from a post by RESTfather [http://roy.gbiv.com/ Roy Fielding] on [http://groups.yahoo.com/group/rest-discuss/message/5369 rest-discuss]; used by permission. The context was a discussion about what Tim Berners-Lee meant by his so-called 'Opacity Axiom', specifically how it applies to REST.)''

= Roy on Opacity in REST =

== Historical Context ==
...In order to understand TimBL's design notes, you have to know about the context in which
he is writing a response. In this case, various thoughts were
recorded as the "Opacity Axiom" in response to a discussion about
client behavior and the perceived need for URNs. It has long
since been taken out of context and abused in various ways.

Also, keep in mind that TimBL's design note was written two
years after Henrik and I [Roy Fielding] worked out the important bits of what
would become the HTTP object model, later re-named REST to get
away from OOM terms, about 18 months after we had similar
discussions at MIT with TimBL and the rest of the W3C team, and
more than a year after HTTP/1.0 was finished and HTTP/1.1 proposed.
So, saying it was something that I "didn't really care to
integrate so much" is missing the mark by quite a bit -- he is
trying to describe our model to people who did not understand it.

== Original Intent ==

The opacity principle, as actually used on the Web, refers only
to the machine interpretation of request processing as being
dependent on control data (e.g., hypertext anchors and message
field names) rather than on metadata appearing within the URI.
It is the same reason why we distinguish media types from data
formats -- the fact that a string of bytes looks like angle tags
doesn't mean we want to process it as HTML. Ignoring any
semantically significant data in a URI allows operations on a
resource to be orthogonal to identification of the resource.

REST does include the opacity axiom in the original sense of
that phrase. I did not use it by name in REST because it isn't
a principle at all -- opacity is just a name TimBL used for the
set of constraints around URI processing by clients (a byproduct
of the constraints that you will find in REST). The principle
involved is orthogonal design.

== Applicability to Clients ==

"Opacity of URI" only applies to clients and, even then, only to
those parts of the URI that are not defined by relevant standards.
Origin servers, for example, have the choice of interpreting a
URI as being opaque or as a structure that defines how the server
maps the URI to a representation of the resource. Cool URIs will
often make a transition from being originally interpreted as
structure by the server and then later treated as an opaque
string (perhaps because the server implementation has changed
and the owner wants the old URI to persist). The server can make
that transition because clients are required to act like they
are ignorant of the server-private structure.

Clients are allowed to treat a URI as being structured
if that structure is defined by standard (e.g., scheme and
authority in "http") or if the server tells the client how its
URI is structured. For example, both GET-based FORM actions and
server-side image map processing compose the URI from a
server-provided base and a user-supplied suffix constructed
according to an algorithm defined by a standard media type.

== The Bottom Line ==

Note, however, that some people have taken the mere title of
"opacity" and assumed that it meant URIs should not have
meaningful construction at all. TimBL's axiom doesn't say
that and neither does REST.

= Summary by Jon Hanna =
(extracted from the microformats-rest mailing list; headers added later)

== Opacity Option ==

I think it's important that URIs *can* be treated opaquely - you can
link to them, you can cache their resources without processing them
beyond naive string-matching, process RDF graphs again without
processing them beyond naive string-matching, and so on.

== Non-Opacity Option ==

This does not preclude the fact that agents *may* construct or parse
URIs in more sophisticated ways, it just means that agents don't have
to, especially in the case of agents that are not aware of the specific
purpose of the application.

= Further Clarification by Roy =

== Not Quite ==

Er, not quite. The key is that the '''server''' is free to tell the client
that there does exist structure in a given URI-space, and then the
client is free to make use of ''that'' knowledge in future requests.
That is how server-side imagemaps worked -- HTML says that the src
URI is structured such that appending "?X,Y" to that URI, where
X and Y are non-negative integers, corresponds to points on a map
that can respond to future GET requests.

Thus, one way for the server to tell the client that a given URI
is structured is to provide the URI in a standard element of a
standard media type that has been defined as such. Another is to
include the URI in a response header field.

== Caveat to the Caveat ==

Note, however, that I am also one of the creators of the robots.txt
standard. That particular scenario requires that the spider find out
the constraints on a site prior to the very first access of a real
hypertext link. It is too late to obtain that information by
looking at header fields after a normal request is made. Adding a
new method to HTTP was out of the question because it would have
to be deployed before it could be used
''[OPTIONS could fulfill that purpose today, 12 years after robots.txt was defined]''.
Adding fields to DNS wasn't an option back then, either. Reserving /robots.txt
remains the best option given the alternatives available.

Note, however, that no other "reserved URI" features have the same
requirements as spiders, so it is still true that favicon and pics
chose the wrong solution.

= Final Comment By Dr. Ernie Prabhakar =

This implies to me that the ''server'' should use an specific microformat to indicate that a given URL can be treated in a particular way. In the absence of a such a microformat, clients should not make any such assumptions; further, servers should avoid requiring clients to understand that microformat in order to receive service.

advocacy

2006-10-20T21:53:29Z

MikeSchinkel: advocacy moved to Advocacy

#REDIRECT [[Advocacy]]

Advocacy

2006-10-20T21:52:50Z

MikeSchinkel: Initial Entry

My goal for this page is to include pointers for how to advocate for Microformats, especially in the wake of the "No, we're going to use XXX instead..." arguments. [[User:MikeSchinkel|MikeSchinkel]] 14:52, 20 Oct 2006 (PDT)

==Brian Suda==
The other great thing about exposing your data as microformats, is that the data becomes Open Data. Will the general public have access to the CalDAV? (probably not) and even if they did, it will probably only serve-up .ics files... what if i don't want ICS? i need to then hack that around to get it into the format that i want... if the data were in the HTML to begin with, then i could EASILY convert that to any format i wanted. Also, sites like http://pingerati.net/ will happily take in hCalendar data and aggregate it, make your data more valuable and easily slurped up by other providers - i don't see that happening as easily with a CalDAV.

==Kevin Marks==
With respect to CalDAV: I spoke to the CalDAV chaps at Apple about this, they have hCalendar support as a ticket in their db:
http://trac.macosforge.org/projects/calendarserver/ticket/19

to-do

2006-10-17T04:36:33Z

MikeSchinkel: /* Information Architecture */ Added "Mike Schinkel's Comments"

<h1>To Do</h1>

This page is for posting [[microformats]] related shared to do items. If you want to use this page for your microformats related to-do items, create a section with your name on it. The reason we are keeping these all on the same page is to make it easier to tell when people are working on similar things, and to make it more obvious when people help out with other people's tasks. In theory this probably won't scale, but let's first see how it does in practice. :) - [http://tantek.com Tantek]

__TOC__

== Lazyweb ==

Just some nice things, feel free to do any of these.

=== for all microformats ===
* quick and easy "how to" pages for each microformat. [[use]] is a good overall start.
* brief summary statements for each microformat that explain why it matters, what does it accomplish for the publisher.
* write up [http://microformats.org/discuss/ mailing-list] questions and answers in the appropriate [[faq]] pages.
* validators. See the hReview section below as there has been a request for an hReview validator in particular. See [http://norman.walsh.name/2006/04/13/validatingMicroformats Norman Walsh's blog post "Validating microformats"] for some valuable analysis and validation pseudo-code (prose description), which are useful steps towards building microformat validators.
* Create a microformat (based on hCalendar?) for marking up the opening hours of stores and restaurants. Some people seem to believe hCalenders repeating event support isn't good enough for this and needs to be amended first.

=== hReview ===
* [[hreview|hReview]] support in Ecto (hey Adriaan!), requested by Andy Smith
* an [[hreview|hReview]] validator.
* a semantic, clean css star rating picker (e.g. a UI widget to rate from 1-5 stars)
** both [http://komodomedia.com/blog/index.php/2005/08/24/creating-a-star-rater-using-css/ this] and [http://factorycity.net/demos/drupal/rating/default.html this] have some flaws. Ask [[User:RyanKing|Ryan King]] for an explanation.

=== hCard ===
* microformatted versions of conference pages
** Do a revision of the [http://conferences.oreillynet.com/etel2006/ ETel] [http://conferences.oreillynet.com/pub/w/44/speakers.html speaker's page] with all the speakers marked up with [[hcard|hCard]] and links to "Add hCards to Address Book" etc., similar to the [http://tantek.com/microformats/2005/web2/speakers.html Web 2.0 speakers page which Tantek did a revision of last fall].
* vcard to hcard converter
** would be nice to have a web upload UI that would take one or more vCards from apple's address book and give them back to you as hCards
** [[User:RobertBachmann | RobertBachmann]] suggests starting points:
*** For Ruby: http://vpim.rubyforge.org/
*** For C: http://freshmeat.net/projects/libvc/
*** For Python: http://www.nongnu.org/python-pdi/
*** For PHP: http://pear.php.net/package/Contact_Vcard_Parse/
* add export support for microformats to [http://www.turingart.com/abForWeb_lan__en.htm AB to Web]
* A mash-up with google maps that will take any url with a hcard (or hcard's) and map the location(s) on a map (similar to [http://austin.adactio.com/ austin.adactio.com])

=== hCalendar/hCard/hReview editor ===
* onblur in the URL field (e.g. on hCalendar), goes out and tries to retrieve an object of same time (e.g. an hCalendar vevent) from that URL and uses it to autofill the form, same thing if the creator is loaded with that URL prefilled (e.g. due to a ?url=http://example.com/ in the URL that loads the creator).

=== WordPress patches for microformats ===
* submit patches for WordPress code/templates for microformats improvement
** <address class="vcard"> improvement in post author publication (e.g. home page of http://microformats.org/ )
* Wordpress plugin for microformats, specifically hReview and hCalendar
** See [http://www.surfarama.com/index.php?p=227 lazyweb request]

=== Yahoo Open Source Library Patches ===

Several of these could very much be improved with a little microformats markup. Do we just make patches and submit them? Contact Nate Koechley at Yahoo (see Tantek for contact info) to follow-up.

* [http://developer.yahoo.net/yui/ Yahoo! User Interface Library]
* [http://developer.yahoo.net/ypatterns/ Yahoo! Design Patterns Library]
* [http://www.yuiblog.com Yahoo! User Interface Blog]

=== Drupal patches for microformats ===
* submit patches for Drupal code/templates for microformats improvement
* Drupal modules for microformats, specifically hReview and hCalendar

=== Adding Markup to Existing Pages (W3C track at WWW2006) ===

* DanC offers a 150 point bounty to anybody who takes [http://www.w3.org/2006/05/w3c-track the W3C track at WWW2006] and adds hCalendar markup and sends it to connolly@w3.org,www-archive@w3.org

===Geotagging on Wikipedia===
Somebody familiar with the "geo" microformat might want to add details, and a link to the relevant page on this Wiki, to the [http://en.wikipedia.org/wiki/Geotagging Wikipedia page on Geotagging].

== Tantek ==

I'm keeping a few microformats related to-do items here both for my own convenience, and for folks looking to help out with small tasks. If so, just create a new section with your name, and and maybe copy the item there, and put your name next to the item in my list. We'll figure this out as we go along. Thanks, [http://tantek.com Tantek].

=== *-authoring microformats wiki pages ===
* Add some tips to [[hcard-authoring]]
** a tutorial on creating an hCard for your site
** specific instructions for common blogging platforms
** instructions for more properties (match at least the set that is in the [http://microformats.org/code/hcard/creator hCard creator])
* Create [[hreview-authoring]] - a tutorial on how to blog reviews so that they'll be aggregated.

=== for all microformat specs ===
* modularize any specs which are > 30K in order to avoid loss/corruption like [http://microformats.org/wiki?title=Special:Contributions&target=Evan Evan's 14 June edits] to [[hcard|hCard]], [[rel-tag]], and [[xoxo|XOXO]].
** [[hcard|hCard]] - need to create new pages for [[hcard-examples-in-the-wild]] (perhaps grouped/ sorted by individuals, organizations, and hosting sites?), [[hcard-implementations]] at a minimum to separate out that content, and leave short summaries in their existing place inline in the [[hcard|hCard]] spec.
** [[rel-tag]]
** [[xoxo]]

==== update specification section organization ====
In particular, the introduction/boilerplate/headers. [[hresume|hResume]] has an experimental abbreviated intro/headers section, and links to more details further below, based on some ideas that Ryan King and I had for improving the readability of the microformats specifications. [[hreview|hReview]] has some similar improvements, but different. We need to:
# Figure out if the new intro/headers structure in [[hresume|hResume]] and/or [[hreview|hReview]] is an improvement, and if it could be better. Perhaps figure out the requirements for an intro/header section
#* Shorter tends to be better
#* Must be comprehensive enough to "print and read"
#* Must detail authorship/editorship
#* Must detail copyright/patent statements
# Write up a template - make it self-documenting per the requirements
# Update existing specifications with the new intro/headers structure.
## [[hcard|hCard]]
## [[hcalendar|hCalendar]]
## [[hreview|hReview]]

==== reorganizing Implementations sections ====

* sort implementations by authoring/creating/publishing, browsing/viewing, converting/importing, indexing/searching.

Hmmm... I like: '''A'''uthoring, '''B'''rowsing, '''C'''onverting, '''I'''ndexing, '''L'''ibraries (for developers), and '''P'''otential (for open source projects we want to add support to). Anybody have alternative suggestions for this vocabulary? I don't have a particularly strong preference so I'm going to go with these four until I find examples that don't fit, or someone suggests something better.

See: [http://microformats.org/wiki/hcalendar#Implementations hCalendar Implementations] for a first attempt at this. Assuming folks like that, we can go ahead with categorizing the implementations sections of other microformats specifications.

==== reorg Examples in the Wild sections ====

* include more *key* details per example, e.g. precise or estimates of counts for services
* collate/sort examples in the wild by
** hosting services - where users/people actively contribute to the growth (e.g. Flickr profile hCards)
** publishing services - where lots of data is published from some datasource/database (e.g. Yahoo! Local)
** companies/groups/organizations member pages (and their own) - pages for a group's site where they list members or employees (e.g. Technorati staff page)
** individiual companies/organizations contact info pages
** individual people's contact info pages
* of course at some point this won't scale, but that will be a very good problem to have, and by then I'm sure we'll have services to point to that provide queries and search results for all this data.

==== summary Examples in the Wild page ====

* need to create a summary / overall [[examples-in-the-wild]] page
** parallel the summary/overall [[implementations]] page.
** use newly reoganized content from the above "reoganizing Examples in the Wild" task

=== iterate on current microformats ===
==== [[hreview|hReview]] ====
* Write hReview 0.3 XMDP profile, and reconcile with [[hcalendar-profile]] and [[hcard-profile]]. Makes sense to have a combined profile of all three for hReview, since hReview normatively depends on hCard and hCalendar.

==== [[hcalendar|hCalendar]] ====
* re-add a list of properties per the [[hcard#Property_List|hCard property list]].
* formalize [http://microformats.org/wiki/hcalendar- brainstorming#Tabular_event_calendars]
* flesh out [[hcalendar-examples]] and do a once over on markup/presentation of what RFC2445 examples would look like
* need spec details and then [[hcalendar-examples]] of multi-instance [[hcalendar|hCalendar]] events
* need spec details and then [[hcalendar-examples]] of repeating events
* add explicit explanation and examples for LOCATION [[hcard|hCards]] and ATTENDEE [[hcard|hCards]], perhaps on a separate [[hcalendar-examples]] page.
* need to resolve all outstanding [[hcalendar-issues]] to-do items.
* create [[hcalendar-profile]] and have folks verify it. note that it will likely need reconciliation with the [[hcard-profile]], especially since [[hcalendar|hCalendar]] normatively depends on [[hcard|hCard]]. Probably makes sense to have a combined profile which hCalendar would use.

==== [[hcard|hCard]] ====
* [[hcard-examples]]
** add examples of [[hcard|hCard]]s with work telephone, mailing address etc.
** add examples of marking up an organization vs. a person, then link to it from [http://microformats.org/wiki/hcard#Organization_Contact_Info hCard spec section on Organization Contact Info].
** add example of organization-name and organization-unit usage.
* Examples in the wild - need to create a new page for them!
** Group examples in the wild according to:
*** Individuals - one card per person, perhaps sort alphabetically
*** Organizations - one card per organization, alphabetical again
*** Institutions (which list more than one person), with a count estimating the # of hCards, e.g. 40k for Avon. Also indicate complexity of information supplied, eg. just name+number vs. complete details
*** Online Profiles (which host profiles for more than one person) with a count estimating the # of hCards, e.g. 3.5m for Flickr.com
*** Online Venues (which provide listings for businesses or organizations) with a count estimating the # of venues, e.g. ~10k for Upcoming.org
*** Speakers Listings (lists of speakers on conference sites) with a count estimating the # of speakers, e.g. ~300 for SXSW 2006.
** help dglazkov markup: http://glazkov.com/blog/archive/2003/12/17/147.aspx

=== introduction / community ===
* microformats-discuss
** introductory email sent to new subscribers needs to direct people to [[process]] and [[how-to-play]]
* Need to add more to the [[naming-principles]], to cover in particular:
** avoid using the same name to mean two things
** avoid using two names to mean the same thing
** seek to keep the microformats vocabulary minimal, memorable, and usable.

=== profiles ===

* update XMDP with new required features:
** ability for one profile to include/import another (rel="import" ?)
** ability to reference an XMDP via rel="profile" (similar to XHTML2 rel value by same name)
** ability/suggestion to reference an XMDP using <a href> in addition to <link>

=== microformat parsing documentation ===
* Add XPath equivalents where appropriate in [[hcard-parsing]]

=== create microformats wiki pages for ===
* *-authoring for all microformats
* *-parsing for all microformats

=== improve usability and automation on the site ===
* figure out how to get wordpress to autopost blog posts to the microformats-announce list
** ideally use the from address of the author of the blog post
** maybe photomatt knows how to do this.

=== help with microformat implementations ===
* wordpress improvements
** WP admin for new profiles
*** should simply read blog URL
*** look for hcards and parse them
* [http://gmpg.org/xfn/creator XFN Creator] localizations
** Get someone to verify the [http://gmpg.org/xfn/creator-ru XFN Creator Russian localization].
** Add it to the [http://gmpg.org/xfn/tools XFN Tools] page.
** Add rel="alternate" href="creator-ru" <link>s to the other XFN Creators.
* Conference Schedule Creator
** We need to ASAP build a simple conference schedule creator (and editor?) that builds upon the hCalendar creator. We should make it *trivial* for conference organizers to build/edit/publish an [[hcalendar|hCalendar]] schedule for their conference, including auto-generated "Subscribe..." link which produces the proper "webcal:..." link with X2V. Note: see the "axis" and "header" attributes in HTML4, specifically in the section on Tables.

=== help with microformat examples in the wild ===
Go over all "common" pages (both logged out and logged in states) of the following sites which have some microformats already, and verify each page is as microformatted as it can be with high fidelity [[hcalendar|hCalendar]] and [[hcard|hCard]] etc. Document full support of each implementation's microformats on the implementations page (perhaps create a separate page for each implementation, e.g. [[flickr]], [[upcoming]], [[eventful]] etc.) Document any exceptions as needed. In no particular order:
* Flickr.com (3.5m hCards)
* Upcoming.org (100k hCalendar events, 100k hCard venues)
** home page
* Eventful.com (100k hCalendar events, 100k hCard venues)
* Yahoo! Tech (300k products with hReviews)
* JudysBook.com (???k hReviews)
* ... lots more, get from "Implementations" and "Examples in the Wild" sections of specs.

=== help with new microformat requests ===
* expense reports (really just a list of "expense" items), [http://flickr.com/photos/edyson/56774178/ requested by ED], should look at UBL as a pre-existing format
* photo-notes microformat
** clean up Subethaedit notes from working session with Greg Elin, Ryan King, Kevin Marks, Suw Charman and email to folks and figure out next steps
** iterate on [[photo-note-examples]] and start [[photo-note-formats]] and [[photo-note-brainstorming]].

* Can we make "microformat" and "microformats" into [http://factoryjoe.com/blog/2006/01/14/the-case-for-community-marks/ Community Marks]?

==Ryan==
=== hCalendar/hCard/hReview creator improvements ===
* get all creators working in IE/Win, IE/Mac, Safari/OSX.3

=== other ===
* add an example of how to use DURATION in hcalendar see http://www.policyawareweb.org/2005/ftf2/paw-mtg#item15) -> verify http://svn.lifelint.com/hcalendar_tests/calendar-todo-multiple-attendees-and-alarm.xml

=== rel-payment ===
* update rel-payment to reference the IANA registry [http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02055.html]

=== hcalendar ===
* make sure we explicitly disallow 'vjournal'

== Dimitri Glazkov ==

* Figure out REST/Microformats thing
* Work on result set idea
* Implement h-creators using Web Forms 2.0

== Chris Messina ==

* Work on a microformat for play-lists (is it just a XOXO ordererd list of play-items?)
* Work on a microformat for play-item (take a look at [[media-info-examples]])
* Work on microformats tutorial for designers

=== Wishlist ===

* Microformat for "buyable items" (see [[listing-examples]] and related documents)
* Location MF -- right click "map this" (see [[geo]] and [[adr]])
* Better hCard support in the browser -- right click "IM this person...", "Add to contacts" (see [http://factoryjoe.com/blog/2006/03/20/flocktails-for-flock/ Flocktails])
* Better hCal support -- support many views of same hCal data on one page using XSLT
* We need something that a designer/web programmer can come to and leave w/ 2 examples of each microformat that they can apply right away... a "microformats styleguide for designers", if you will.
* invoicing microformat
* better microformats wiki theme

== Robert Bachmann ==

=== hCard Creator ===
* [http://microformats.org/code/hcard/creator hCard creator] - add features/fields
** aim / instant messaging contact info, using the techniques documented in [[hcard-examples#New_Types_of_Contact_Info|hCard Examples: New Types of Contact Info]]
*** consider a popup menu for the IM service (AIM|Yahoo|...), and a field next to it for the IM id.

=== hAtom2Atom ===

Some ideas for features which could be implemented :

(If you are interested in one of this features, add "+1 Your Name")

<ul>
<li>
Join all hfeed's inside a page (or a fragment thereof) into one feed using [http://greenbytes.de/tech/webdav/rfc4287.html#element.source atom:source] semantics.
</li>
<li>
Extraction of <code>atom:content</code>, <code>atom:summary</code> and <code>atom:title</code>:
* <code>atom:content</code> and <code>atom:summary</code> as HTML
* <code>atom:content</code> and <code>atom:summary</code> as plain-text
* <code>atom:title</code> as XHTML
* <code>atom:title</code> as HTML
</li>
<li>Support for other XSLT engines:
* MSXML
* .Net System.Xml
* Sablotron
* Oracle XSLT
* XT
</li>
<li>Support for other output formats: (hAtom2xyz.xsl)
* RSS 2.0 (meanwhile use hAtom2Atom.xsl and [http://atom.geekhood.net/ atom2rss.xsl])
* RSS 1.0 (meanwhile use hAtom2Atom.xsl and [http://cvs.4suite.org/viewcvs/uogbuji/atom2rss.xslt atom2rss.xslt])
* AtomOWL (meanwhile use hAtom2Atom.xsl and [http://dannyayers.com/2005/11/22/atomowl-xslt-progress/ atom2rdfxml.xsl])
* JSON?
** Does it make sense to consider a canonical representation of microformats (either case by case, or in general) in JSON? E.g. so that a JSON API that returned contact information could return an hCard-equivalent chunk of JSON. - Tantek.
</li>
</ul>

([[User:Singpolyma|singpolyma]] 01:02, 9 May 2006 (PDT) -- Not XSLT, but see http://xoxotools.ning.com/hatom2rss.php for hatom to RSS2.0 conversion)

== Brian Suda ==
=== Citation Microformats ===
* Add all my notes to the Wiki
* Start the process of naming the properties using existing names

=== X2V ===
Make changes and update site (almost stable)
Get ATTENDEE and other strange attributes working
==== WARNINGS and ERROR ====
work on the warnings and error output for the pre-check in X2V

=== FAQ ===
* clean-up the MF FAQs
* clean-up FAQs from the major microformats
* pull Questions from the mailing list and document them to the FAQs and example

== Mark Rickerby ==

=== Current Tasks ===

* Follow up on usability review
** Edits to homepage feature box text
** Draft of [[getting-started]] page
* Review content for new pages - [[start-simple]], [[modularity]], [[reuse]], [[humans-first]]
* xoxo datatype examples
** test case lists
** transmitting key/value lists
* practical feedback on hresume

=== Wishlist ===

* hmmm

== Ernest Prabhakar ==
=== Wiki-Thon Proposal ===
Set aside several hours (probably a Friday night US PST) for focused work on the Wiki, including both physical (e.g., a room in the Bay Area) and virtual (IRC/iChat) participants.

==== Goals ====
# Improve understanding of what needs to be done for Wiki
#* IMHO - this should be done here, in [[to-do]] incrementally. -Tantek
# Tackle larger projects (~1-2 hours) than people usually have time for
#* I'd like to see these projects *documented* first on [[to-do]] before we spend 1-2 hours of a bunch of folk's collective time to go through them. -Tantek
# Motivate community to have fun with otherwise tedious "housecleaning" chores

==== Agenda (Wishlist) ====
In parallel:
* Coalesce/prioritize existing To-Do items (above)
* Review/revise desired pathways for:
** New users learning about microformats
*** e.g., intro, about, explore, tutorials, etc.
*** cf. [http://www.rubyonrails.com/ Rails] front page
****Get Excited (Why, background, motivation)
****Get Started (What, downloads, getting started)
****Get Better (How, tutorials, )
****Get Involved (Who)
** Microformat lifecycle
*** e.g., research->brainstorm->proposal->spec->maintain
*** see http://theryanking.com/microformats/method.txt --[[User:RyanKing|RyanKing]] 15:35, 22 Feb 2006 (PST)
*** ensure information easy to find, follow, and up-to-date
* Review existing specs for completeness and consistency
* Identify areas of 'bitrot' or 'hole-filling'
* Do it!

== Dan Connolly ==

[[User:DanC|DanC]] hopes to sync up on these tasks in [[irc]] roughly
weekly, during Wednesday afternoon (Chicago time) "office hours". See also my [http://esw.w3.org/topic/DanConnolly esw todo list and someday pile].

* from SxSW in Austin
** build a combined hcalendar/hcard profile; resolve issues in [[profile-uris]].
*** with XSLT transformation to RDF
** finish [[hcard-tests]]
*** figure out [[include-pattern]] boundaries

* Medium term
** sync [[hcalendar-tests]] and [http://www.w3.org/2002/12/cal/ RDF calendar] tests and CALSIFY
*** reconsider RDF calendar naming conventions
** update my CV/resume using [[hResume]] and [[citation-formats]]
*** get an answer from the CALSIFY WG re [http://lists.w3.org/Archives/Public/www-rdf-calendar/2006Apr/0006.html dtstart and date vs datetime ] 21 Apr 2006
*** refine [[hatom]] so that it's suitable for the workflow around the W3C homepage.

* from WWW2006
** follow up on GRDDL as escape valve for microformats proposals, much like CSS was an escape valve for HTML tag proposals.

* Someday pile
** set up a timezone registry based on wikipedia and semantic mediawiki. As discussed in [[datetime-design-pattern]], iCalendar's by-value timezone passing is broken. see [http://lists.w3.org/Archives/Public/www-rdf-calendar/2006Apr/0002.html reconsidering timezones in light of hCalendar and CALSIFY] and [http://dig.csail.mit.edu/breadcrumbs/node/91 Toward Semantic Web data from Wikipedia]
** noodle on a playlist format and some of the media RSS stuff like [[media-info-brainstorming]], [[media-metadata-examples]] (re playlists: XSPF, SMIL, RDF, and microformats 9 Sep 2005)
** check out that hReview bug stuff...
** noodle on [[meeting-minutes-brainstorming]] and [http://esw.w3.org/topic/MeetingRecords MeetingRecords in the esw wiki].
** noodle on clipboard scenarios, esp how RDFa works in the general case but isn't as author-friendly as domain-specific syntaxes.

[[User:DanC|DanC]] 15:39, 31 May 2006 (PDT)

== Chris Casciano ==

[[User:ChrisCasciano|ChrisCasciano]]

* get around to updating [[hatom-issues]] with some multi feed rules/exceptions.
* <del>Update textpattern plugin with simple hreview support and get a new release out</del>
* Redesign placenamehere.com and include hatom
* Follow up with technorati folks on pingerati reviews getting lost (note: this will require publishing more reviews and theen watching them through the update process)
* <del>prototype a NetNewsWire microformat extractor (CSS+AppleScript)</del>

== Drew McLellan ==

[[User:DrewMcLellan|DrewMcLellan]]

* Build an hReview profile for [http://allinthehead.com/hkit/ hKit] and test
* Update the [http://www.webstandards.org/action/dwtf/microformats/ Dreamweaver extensions] to mirror recent changes in the online builders
* <del>Publish an hCard to JSON service on [http://tools.microformatic.com/ tools.microformatic.com] using hKit.</del>
* Further develop blog comment form hCard collection ideas.
* Version of hReview creator using hKit to import business details from an hCard

== Christophe Ducamp (french localization) ==

[[Christophe Ducamp]]
* translate exploraty discussions (red links on [[to-do-fr]]
** find experts for peer-reviewing
* localize an french version of the official website
** find out the original versions of pictures (in SVG ?)
** find out french skills resources to adapt the original webdesign

== Frances Berriman ==

[[User:Phae|Frances Berriman]]

* Work on styles for [[zen-garden]] project.
* Style HTML cheatsheet to match Brian Suda's PDF.
* Write simplified help/implementation documents (how tos) for all finalised Microformats.
* (Feel free to add suggested tasks to my list)
* Help converge on organization efforts ~bewest :-)

== Ben West (bewest) ==

[[User:BenWest|bewest]]
=== Creators ===
* <strike>Start hatom creator.</strike> http://dichtomize.com/uf/hatom/creator.html
* Code Reuse. These creators are downright handy, and I’ve reimplemented the vcard one on my own site. Instead, let’s make these widgetized. Let’s decide on a more or less canonical html structure and create some javascript that will create the desired microformat. Something as easy to use as new Microformat.hCard($('mycontainer')); would be awesome. Right now, if someone makes an improvement to the hCard creator, the other creators don’t get the benefit. Spec this out!
* About Section. Is there an official creator page? If so, let’s point to that. The about paragraph is getting longer and longer with phrases like “which is based on…” repeated over and over.
* Default all dates to “right now”. Provide an easy to use calendar type widget to change dates.
* hAtom creator: Add multiple. It’d be nice to add an arbitrary number of entries.
* hAtom creator: Optional feed enclosure. Check box to wrap the entry/entries in an hfeed.
* Edit URI: Allow someone to enter a URI and edit whatever microformat is found on the page.
* Optionals. If the format requires, say, a vcard, the creator can defer to an external URI or can trust the user to fill it in later.
* Common stylesheet. I suppose this goes with the reuseable code idea… we have many great coders, we should be reusing eachothers’ work.
* Use Amazon's ECS to pull in information about products when there is an ASIN in the item URI.

=== Information Architecture ===
'''Help Welcomed! Please leave your name'''
Add complaints to [[wiki-feedback]]!
Helping to make the wiki easier to use. I'd like to see the main page more towards a format like http://simile.mit.edu/solvent/ with the big questions right out front:
* What Is This?
* What can I do here?
* Is there a demo?
* Where can I learn more?
I'd like to change the front page to this kind of design.
==== Support Pages ====
There are several categories of things in the wiki. Can we enumerate them?
* About the Community
** Where to find information.
** Who are the stake holders?
** FAQs
* Web/Architectural Philosophy
** Community Principles
** Why are we doing this?
** XML and Namespaces
** Semantic XHTML
** Common Misconceptions
** Concession and Disposition of Criticism
** FAQs
* Specs
** Examples
** Discussion
** Exploration
** Use Cases
** Implementations
** The spec itself.

Can others agree and or refine this list? Should I take it to the -discuss list? How do we create consensus on how the wiki should be organized in order to make it more usable? And how can we turn that consensus into actionable changes?

Considering that the wiki page named with the microformat (i.e. /wiki/hcard) is the one that people will mostly likely look to first for learning about a particular format, I'd think it'd make more sense and create a more welcoming feel to convert these pages to an intro page introducing the format for the beginner and linking to resources like tutorials and creators. Spec pages would then be relocated to wiki/*-spec -- [[User:Cgriego|Cgriego]] 13:25, 16 Oct 2006 (PDT)

====Mike Schinkel's Comments====

My suggestion on the list was for us to use a convention that the entry page (i.e.
http://microformats.org/wiki/hcard) would be an index into a list of
(psuedo) standardized sub pages so that it would be very people to
find what is important to them. For example, is a list of potential sub pages:

* Microformat
** Specification
** Tutorial
** Examples
** Use cases
** Reference
** Discussion
** Brainstorming (might be combined w/Discussion)
** Implementations
** Related Pages
** Further Reading
** All (Uses Mediawiki's "includes" to create a page including all sub pages; very useful for printing & reading offline)

These pages would be located respectively at

* http://microformats.org/wiki/hcard/
** http://microformats.org/wiki/hcard/Specification
** http://microformats.org/wiki/hcard/Tutorial
** http://microformats.org/wiki/hcard/Examples
** http://microformats.org/wiki/hcard/Use_cases
** http://microformats.org/wiki/hcard/Reference
** http://microformats.org/wiki/hcard/Discussion
** http://microformats.org/wiki/hcard/Brainstorming
** http://microformats.org/wiki/hcard/Implementations
** http://microformats.org/wiki/hcard/Related_Pages
** http://microformats.org/wiki/hcard/Further_Reading
** http://microformats.org/wiki/hcard/All

Please note I am suggesting an architecture not a specific list of sub pages. The list of sub pages should be defined by both reviewing existing information during site reorganization, and then via discussion on the list in an attempt to discover and extract which sub pages are needed for most/all microformats.

'''NOTE''': This differs from above in that the spec if not viewed as a top level structure but instead the microformat itself and the spec would be under the microformat. In this context "microformat" is a more abstract concept and "spec" is a more concrete thing. Another way to think about it would be that each microformat would have it's own mini home page and then things like "spec" are the pages listed on its home page.

== New Person 1 ==

etc.

currency-brainstorming

2006-10-13T03:27:59Z

MikeSchinkel: Added "Mike Schinkel" section

== Brainstorming ==

Brainstorming for the proposed [[currency]] microformat.

===Ben Buchanan===
Verbose but extensible and explicitly defines all values (without breaking DRY):

<pre><div class="currency">

code
symbol
12345

</div></pre>
"figure" is there to both explicitly associate the code, sign and amount but also allow the potential for more than one currency figure to be placed within the container. It does anticipate further development though and is the most easily dropped item at the early stage.

Without figure:
<pre><div class="currency">
code
symbol
12345
</div></pre>

Super shortened, relying on the parser to identify everything via implied order/structure:

<pre><div class="currency">ABC12345$</div></pre>

Although the simplest solution, it has a notable vulnerability: some currencies have/had three-letter abbreviations for their currency sign, instead of a symbol. This would make it very difficult for a parser to accurately identify such a currency.
In addition, it should be noted that the order alone cannot be used to identify which parts are code, sign and amount; since many currencies are denoted with the sign after the number.

Super shortened, but specifying a currency code as a class:

<pre><div class="currency ABC">12345$</div></pre>

It defines...

<ol type="a">
<li>we're talking about money - ISO standard implied,</li>
<li>we're talking about the USD variety,</li>
<li>we're talking fifty units of that money,</li>
<li>a parser could work out the numbers and the symbol.</li>
</ol>

The biggest limitation I can see for that shorthand is that the currency code is not displayed visibly to human readers. The currency code is useful information to viewers and ideally should be displayed.

Shortened (including dropping 'figure', but explicitly defining and displaying the currency code. This would allow a parser to treat any remaining numbers as the amount; and any remaining a-z or symbol as the sign:

<pre><div class="currency">
ABC12345$
</div></pre>

===Charles Iliya Krempeaux===
Maybe something like...

<pre>Pay me <abbr class="currency" title="CAD">$</abbr>5.00 now!</pre>

Although something like the the following might be better...

<pre>Pay me <abbr class="currency" title="CAD">$</abbr>5.00 now!</pre>

But it might be more semantic salt than is considered necessary. Just having the abbr with the class-currency near a number might be good enough. But that's open for discussion though.

=== Ben Ward ===
Could pure HTML be sufficient?
<pre><html lang="en-gb">
My new T-Shirts cost £30, but it cost my friend in Canada $34
</html></pre>

===Arve Bersvendsen ===
<pre>Den kanadiske prisen på t-skjorten var 34 $.</pre>

=== Mike Stickel ===
<pre><abbr class="currency" title="CAD eng">$</abbr>5.00</pre>
In this format the wrapping would be "money" or something similar followed by either the actual "amount" or the "currency", depending on what rules your country/language follows in regards to the order.
Since there can be a difference between different languages within countries I thought it might be a good idea to include that in the "currency" definition of the formating, eg., "CAD eng" or "CAD fr".
It could also give sites that list multiple languages a way to differentiate when they show multiple prices.

=== Ciaran McNulty ===
The only microformat that I've noticed currency units in is [[hListing]], and that deliberately shies away from parsing the actual values because it's too free-form in most existing Listing formats.

My own preference would be for something like:
<pre>This item costs
GBP
10.00
</pre>

Which with similar parsing rules to existing formats would also allow things like:
<pre>
It'll cost you
<abbr class="currency" title="50.00">fifty</abbr>
<abbr class="amount" title="GBP">quid</abbr>
, mate!
</pre>
Or, a more complex example with multiple languages:
<pre>
Price:

<abbr class="currency" title="GBP">£</abbr>
1,250.00


(Prix:
1600,00
<abbr class="currency" title="EUR">€</abbr>
)

</pre>

===Andy Mabbett===

====Straw man proposal====

(this reflects Ciaran McNulty's proposals, above)

In order to use currency as a sub-class, the parent should be named 'money'

*money - class (required) '''[or "currency"?]'''
**currency - class (required; uses ISO 4217) '''[or "type"?]'''
**amount - class (required) '''[or "value"?]'''
**year - class (optional - for historic values only) (better "'''date'''", in [[datetime-design-pattern]]. Consider inflation in Germany in 1930s!)
**symbol - class (optional - so that we know whether the symbol is present; or whether it needs to be generated by the user agent; it will also help user agents to ignore $ and other such symbols, when used for purposes other than to indicate a currency, or to remove them, when translating to a different currency.)
**unit - class (subdivison of currency; use as "symbol")
**equivalence - class (optional; conversion should be done by the user agent. Do we need this? Does it need a numeric value?)

All classes may occur only once, apart from ''symbol'' (to allow for "£14 6s 2d") and ''unit'' (to allow for "five pounds 23 pence").

=====Examples=====
Thus:

<pre><nowiki>
A widget costs
<abbr class="currency symbol" title="USD">$</abbr>
12.57

</nowiki></pre>

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="money">
<abbr class="currency" title="USD">
42.67
</abbr>
</td>
</tr>
</nowiki></pre>

<pre><nowiki>

Can you spare
<abbr class="amount" title="10">ten</abbr>
<abbr class="currency" title="USD">
dollars
</abbr>?

</nowiki></pre>

<pre><nowiki>

It was worth
<abbr class="amount" title="0.5">50</abbr>
<abbr class="currency" title="GBP">
pence.
</abbr>

</nowiki></pre>
(note, in the above, that "unit" does not relate directly to the amount in the amount's title abttibute - it's 0.5 pounds, not 0.5 pence.)

<pre><nowiki>
In
1857
a Dickens novel cost
<abbr class="amount" title="0.05">1</abbr>
<abbr class="currency" title="GBP">
<abbr class="symbol unit" title="shilling">/</abbr>
</abbr>

</nowiki></pre>

(The above might be rendered as "... 1/ (worth £4.50 in modern terms" (or whatever the value would be).)

<pre><nowiki>

<abbr class="amount" title="14.32">
<abbr class="currency" title="GBP">
<abbr class="symbol" title="pound">£</abbr>14
</abbr>
6<abbr class="unit" title="shilling">s</abbr>
4<abbr class="unit" title="old-penny">d</abbr>
</abbr>

</nowiki></pre>

<pre><nowiki>

<abbr class="equivalence" title="EUR">
<abbr class="currency" title="FFR">10</abbr>
</abbr>

</nowiki></pre>

The following, simplified for clarity, from [http://en.wikipedia.org/wiki/1922_in_Germany#Inflation_and_Repercussions]:

<pre><nowiki>
On

<abbr class=date" title="1922-08-01>August 1</abbr>,
the US Dollar still stood at
643
<abbr class="type="GDM">Marks</abbr>

to the Dollar. But on

<abbr class=date" title="1922-09-05>September 5</abbr>
the dollar had already risen to
1,440
<abbr class="type="GDM">Marks</abbr>

</nowiki></pre>

Is there anything sensible which ''can't'' be done with the above?

=====Assumptions=====

*Working out values in secondary currencies is a (real-time or daily) job for server-side scripting or user agents.

*If "£" is an abbreviation, then its title is "pounds sterling"; though note that "£5" is pronounced as "five pounds sterling" (commonly just "five pounds") and not: "pounds sterling five" in the same way that "$5" is pronounced as: "five dollars" and not "dollars five"

=====Issues=====

*There will be complications where the entire currency has disappeared, (such as the last example; French Francs into Euros).

* Where no symbol or unit is involved (chiefly in tables, where they will be in the header cell), should we allow:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="money USD amount">42.67</td>
</tr>
</nowiki></pre>

===Guillaume Lebleu ===

In the context of a hListing's price, without a unit:

<pre>
<abbr class="currency" title="EUR">€</abbr>100
</pre>

Rendered view:

<abbr class="currency" title="EUR">€</abbr>100

In the context of a hListing's price, with a unit:

<pre>
<abbr class="currency" title="USD">$</abbv>25 per
barrel
</pre>

<pre>
25 <abbr class="currency"
title="USD">$</abbr><abbr class="unit" title="BLL">/bbl</abbr>
</pre>

Note: the class "amount" may not always be required, but it is useful when the amount is represented as text, or when the amount is mixed within text. See historical example below.

Rendered view:

<abbr class="currency" title="USD">$</abbr>25 per
barrel

25 <abbr class="currency"
title="USD">$</abbr><abbr class="unit" title="BLL">/bbl</abbr>

Outside of the context of a hListing (not all currency amounts are prices, for instance sales numbers):

<pre>
<abbr class="currency" title="EUR">€</abbr>100
</pre>

Historical price (here currency rate):

<pre>
On <abbr class="datetime"
title="1998-03-12T08:30:00-05:00">August 1</abbr>, the US Dollar still
stood at 643 <abbr class="currency"
title="DEM">Marks</abbr> to the Dollar.
</pre>

In a table:

<pre>
<table>
<tr>
<th class="currencyamount price">Price (<abbr class="currency" title="CAD">C$</abbr>)</th>
</tr>
<tr>
<td>100</td>
</tr>
</table>
</pre>

Rendered view:

<table>
<tr>
<th class="currencyamount price">Price (<abbr class="currency" title="CAD">C$</abbr>)</th>
</tr>
<tr>
<td>100</td>
</tr>
</table>

=== Gary Jones ===

<pre><nowiki>

<abbr class="type" title="CAD">$</abbr>
5.00

</nowiki></pre>

Renders as:

<abbr class="type" title="CAD">$</abbr>5.00

If the formatting of a currency is such that the type symbol comes after the value, then simply swap the order of the type and value elements.

I do think that the use of "type" and "value" classes would be better than variations of "currency_symbol" and "amount". It follows the same principles as some other elemental formats ([http://microformats.org/wiki/hcard#Value_excerpting value excerpting]), meaning it's [http://microformats.org/wiki/naming-principles#Minimal_Vocabulary easier to remember] and implement, and even ISO4217 has codes for "currencies" that don't use symbols:

<pre><nowiki>

23 ounces of
<abbr class="type" title="XAG">gold</abbr>

</nowiki></pre>

Renders as:

23 ounces of <abbr class="type" title="XAG">gold</abbr>

Following on from this, the use of a "money" class should not be used; currency does not ''have'' to be money, and having a "metal" class starts to make it convoluted. Currency is the parent of money, not the other way around.

===Mike Schinkel===
I'm taking Andy Mabbett's post and applying my thoughts to his.

Rather than:

<pre><nowiki>
A widget costs
<abbr class="currency symbol" title="USD">$</abbr>
12.57

</nowiki></pre>

Why not just:

<pre><nowiki>
A widget costs $12.57
</nowiki></pre>

In the above, a number is assumed because their is not an "amount", and the number digit is the currency symbol. I guess what I'm saying is if there is a number in the HTML and it is the correct number (which I think will be the 80 percentile case, give or take, then why require additional markup for it?)

Rather than:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="money">
<abbr class="currency" title="USD">
42.67
</abbr>
</td>
</tr>
</nowiki></pre>

Just:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td class="currency" title="USD">42.67</td>
</tr>
</nowiki></pre>

Or:

<pre><nowiki>
<tr>
<th>Spaghetti-knitter</th>
<td>
42.67
</td>
</tr>
</nowiki></pre>

In this case, which is a little more complicated:

<pre><nowiki>

Can you spare
<abbr class="amount" title="10">ten</abbr>
<abbr class="currency" title="USD">
dollars
</abbr>?

</nowiki></pre>

Why not use the following:

<pre><nowiki>
Can you spare

<abbr class="amount" title="10">ten</abbr>
dollars
?
</nowiki></pre>

Here:

<pre><nowiki>

It was worth
<abbr class="amount" title="0.5">50</abbr>
<abbr class="currency" title="GBP">
pence.
</abbr>

</nowiki></pre>

Why not?

<pre><nowiki>
It was worth

<abbr class="amount" title="0.5">50</abbr>
pence
?
</nowiki></pre>

I'm not going to try to mark up the following two since, thus far, [http://www.vizu.com/poll-vote.html?n=15067 no one has voted for dated money amounts or non-numerical representations] (those might be better expressed in their own microformat: [[hHistoricalCurrency]]?):

<pre><nowiki>
In
1857
a Dickens novel cost
<abbr class="amount" title="0.05">1</abbr>
<abbr class="currency" title="GBP">
<abbr class="symbol unit" title="shilling">/</abbr>
</abbr>

</nowiki></pre>

<pre><nowiki>

<abbr class="amount" title="14.32">
<abbr class="currency" title="GBP">
<abbr class="symbol" title="pound">£</abbr>14
</abbr>
6<abbr class="unit" title="shilling">s</abbr>
4<abbr class="unit" title="old-penny">d</abbr>
</abbr>

</nowiki></pre>

I don't understand what this is trying to accomplish (it seems incomplete), so I can't mark it up.

<pre><nowiki>

<abbr class="equivalence" title="EUR">
<abbr class="currency" title="FFR">10</abbr>
</abbr>

</nowiki></pre>

Again, I'm not going to try to mark up given [http://www.vizu.com/poll-vote.html?n=15067 the lack of interest in dated money amounts]:

<pre><nowiki>
On

<abbr class=date" title="1922-08-01>August 1</abbr>,
the US Dollar still stood at
643
<abbr class="type="GDM">Marks</abbr>

to the Dollar. But on

<abbr class=date" title="1922-09-05>September 5</abbr>
the dollar had already risen to
1,440
<abbr class="type="GDM">Marks</abbr>

</nowiki></pre>

My efforts attempt to minimize the disruption in the HTML file and only use additional markup when absolutely required. I believe some high volume websites still try to minimize the markup they serve, and this is bloated as it it. They may decide just to serve up a few digits rather than 50 character per price, especially on pages with lots of prices.

==References==
* [http://www.iso.org/iso/en/prods-services/popstds/currencycodeslist.html The official list of ISO-4217 alphabetic and numeric codes]
* [http://en.wikipedia.org/wiki/ISO_4217 Wikipedia: ISO 4217]
*[http://en.wikipedia.org/wiki/List_of_circulating_currencies Wikipedia: List of circulating currencies]

User:MikeSchinkel

2006-10-12T04:31:59Z

MikeSchinkel: Added my name

=Mike Schinkel=

==Blogs==
* http://www.mikeschinkel.com/blog/
* http://www.thoughtsonsalesforce.com/

==Projects==
* http://www.welldesignedurls.com/

User:MikeSchinkel

2006-10-12T04:31:35Z

MikeSchinkel: Initial entry

==Blogs==
* http://www.mikeschinkel.com/blog/
* http://www.thoughtsonsalesforce.com/

==Projects==
* http://www.welldesignedurls.com/

xoxo-faq

2006-10-12T04:30:14Z

MikeSchinkel: Need help understanding XOXO's benefits and use cases

= XOXO FAQ =

This page documents questions and answers regarding the [[xoxo]] (Extensible Open XHTML Outlines) format.

== I don't understand what benefits xoxo provides ==
Color me dense, but I can't for the life of me figure out what XOXO offers. I read about syntax on this wiki, but not about use cases or benefits. Please help me understand! Thanks in advance. [[User:MikeSchinkel|MikeSchinkel]] 21:30, 11 Oct 2006 (PDT)

== the 'compact' attribute ==

''Q: why is compact/expanded expressed via a new attribute and not by a style class? Wouldn't it be more compatible to simply use a style class?''

A: The 'compact' attribute is not a new attribute. It is defined in XHTML Modularization, and has been in HTML (4, 3.2, 2) since [http://www.w3.org/MarkUp/HTMLPlus/htmlplus_31.html HTML Plus]. Whenever possible it is better to reuse an existing HTML attribute for semantics, instead of a style class. The essay [http://tantek.com/log/2002/12.html#L20021216 A Touch of Class] discusses such semantic nuances in more detail.

''Q: Follow-up: wouldn't a style class ''applied to the sub-outline's parent <code><li></code> element'' allow control over the rendering of the outline and its subject (e.g. adding an expand/collapse widget as a bullet-point)?''

A:See previous A: it is better to reuse an existing HTML attribute for semantics, rather than a style class. A style rule can be written to utilize the "compact" attribute just as easily as the "class" attribute, and then allow control over rendering of the outline and its subject.

''Q: Follow-up: Is 'compact' supposed to remove borders and spacing around a list?''
A: No. Please RTFM. [http://www.w3.org/TR/html401/struct/lists.html#adef-compact HTML 4.01 on the 'compact' attribute]: "When set, this boolean attribute gives a hint to visual user agents to render the list in a more compact way." And rendering the list in a more compact way (in particular, fully compacted) is exactly what [[xoxo]] specifies for the 'compact' attribute.

''Q: Why isn't the XForms "appearance" attribute used instead of "compact"?''

A: Why should the XForms "appearance" attribute be used? There is no need for it, nor is there any need for a second namespace to make simple things more complicated than they need to be.

''Q: Why is the 'compact' attribute, which was deprecated in the HTML4 specification, used in the XOXO format? Isn't it better not to use any deprecated elements or attributes?''

A: The 'compact' attribute as specified in HTML4 is purely presentational and as such was deprecated. Since this attribute has been little used, we have repurposed it as a semantic attribute in XOXO that actually preserves the state of whether or not the ''user'' has twiddled an an outline item and all its children in the open state vs. the closed state. We recycled the 'compact' attribute instead of making a new attribute to minimize reinvention, and to make an otherwise useless attribute useful again.

== class="xoxo" ==

''Q: Why don't MarkP's examples use <code><ol class="xoxo"></code> ?''

A: The use of <code>class="xoxo"</code> is optional for XOXO authors and user agents.

== other markup in xoxo ==

''Q: MarkP uses <code></code> in some of his examples. Is that allowed? If yes, shouldn't <code></code> then be added to the description of XOXO's "document type" (see above)?''

A: Yes, additional elements and/or attributes are allowed per XHTML Modularization, and no, all such possible additions (e.g. <code></code>) don't need to be added to the XOXO document type since XOXO user agents may simply treat them according to the XHTML Modularization user agent conformance requirements (4-6):
1. ...
2. ...
3. ...
4. If a user agent encounters an element it does not recognize, it must continue to process the children of that element. If the content is text, the text must be presented to the user.
5. If a user agent encounters an attribute it does not recognize, it must ignore the entire attribute specification (i.e., the attribute and its value).
6. If a user agent encounters an attribute value it doesn't recognize, it must use the default attribute value.

== xoxo properties and values ==

''Q: Can an XOXO item have a multi-valued property, or a property with multiple values?''

A: Yes. Here is how you would do that:
<pre><nowiki>
<ol class='xoxo'>
<li>item 1
<dl>
<dt>multivalproperty1</dt>
<dd><ul>
<li>value-a</li>
<li>value-b</li>
</ul></dd>
</dl>
</li>
</ol>
</nowiki></pre>