Microformats Wiki - User contributions [en]

datetime-design-pattern

2008-08-06T19:08:48Z

Guillaume Lebleu: /* Individual markup of each date/time component */ corrected header

<h1> Datetime Design Pattern </h1>
This is a page for exploring a datetime design pattern.

{{TOC-right}}

== Purpose ==
* Use the [[datetime-design-pattern]] to make datetimes that are human readable also formally machine readable.

== Practical Need ==
* This design pattern arose as a result of solving the practical need for human readable dates for [[hcalendar|hCalendar]].

== How to use it ==
* enclose the human-friendly datetime that you want to make machine readable with <code><abbr></code>
* as per the [[class-design-pattern]], add the appropriate <code>class</code> attribute to the <code>abbr</code> element
* add a <code>title</code> attribute to the <code>abbr</code> element with the machine readable [[iso-8601|ISO8601]] datetime or date as the value

==Current uses==

The pattern, which is now available as part of [[hAtom]], [[hcalendar|hCalendar]], [[hcard|hCard]] and [[hreview|hReview]], is:

:<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">Date Time</abbr></pre>

where foo is the semantic classname which is being applied to this date/time, the title of the <abbr> is an ISO 8601 date/time, with an appropriate level of specificity, and "Date Time" is a human-friendly representation of the same date/time.

An alternative, if you are using UTC-based timestamps, would be:

:<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SSZ">Date Time</abbr></pre>

with a single "Z" as per [[iso-8601|ISO 8601]]

Ruby: An easy way to get this format from a DateTime is this:
:<pre>DateTime.now.to_s</pre>

== Profile of ISO8601 ==

Any [[microformat]] using the date-time-design pattern {{should}} use a profile of [[iso-8601|ISO8601]]. There are currently two widely used profiles which {{should}} be reused.

* RFC 3339
* [http://www.w3.org/TR/NOTE-datetime W3C Note on Datetimes]

==Accessibility issues==

Note: Some accessibility issues have been raised([http://www.webstandards.org/2007/04/27/haccessibility/]) with Datetime Design Pattern, and concerns that its use could breach WCAG accessibility guidelines, that are being addressed as part of the [[abbr-design-pattern-issues]] discussion. Possible change recommendations may follow after the accessibility testing is complete. The accessibility concerns are considerably lessened, even eliminated when using the [[date-design-pattern]], a subset of the [[datetime-design-pattern]].

== Discussion ==
This pattern is likely to be highly resuable.

--[[User:RyanKing]]

Can this not be viewed as a microformat in itself?

--[[User:DimitriGlazkov]]

It could, but inventing a microformat for the sake of inventing a microformat is against the microformat principles.
If there is a specific real world problem (and uses cases) that such an elemental microformat would solve, then it would be worth considering.

Until then it is best to keep the <abbr> datetime concept merely as a microformat design pattern, to be used in _actual_ microformats that have a demonstrated practical need.

-- [http://tantek.com/log/ Tantek]

Excerpt from #microformats Aug 18th. Please edit!

<pre>
Aug 18 15:16:14 <Tantek> DanC, what do you think of RFC3339?
Aug 18 15:17:14 <Tantek> ISO8601 subset
Aug 18 15:17:19 <DanC> Date and Time on the Internet: Timestamps http://www.ietf.org/rfc/rfc3339.txt
Aug 18 15:17:30 <DanC> Klyne is a good guy. I wonder if I talked with him about this.
Aug 18 15:17:32 <Tantek> compat with W3C-NOTE-DATETIME
Aug 18 15:17:50 <Tantek> compat with xsd:dateTime
Aug 18 15:17:57 <Tantek> it's a strict intersection subset
Aug 18 15:17:59 <DanC> I consider W3C-NOTE-DATETIME obsoleted by XML Schema datatype-- yeah.. xsd:dateTime
Aug 18 15:18:32 <Tantek> compare/contrast normatively using xsd:dateTime vs. RFC3339
Aug 18 15:18:41 <Tantek> note: Atom 1.0 chose RFC3339
Aug 18 15:18:50 <Tantek> i would like input from the microformats community on this
Aug 18 15:19:27 <DanC> in what context are you evaluating RFC 3339?
Aug 18 15:19:28 <jcgregorio> http://bitworking.org/news/Date_Constructs_in_the_Atom_Syndication_Format
Aug 18 15:21:24 <DanC> which microformat is the question coming from, Tantek ?
Aug 18 15:23:31 <DanC> " The grammar element time-second may have the value "60" at the end of
Aug 18 15:23:31 <DanC> months in which a leap second occurs" The XML Schema WG is in the 27th level of
leap-second-hell for the past few months, I gather.
Aug 18 15:24:21 <DanC> yeah... here's the scary bit: " Leap seconds cannot be predicted far into the
future. The
Aug 18 15:24:21 <DanC> International Earth Rotation Service publishes bulletins [IERS] that
Aug 18 15:24:21 <DanC> announce leap seconds with a few weeks' warning."
Aug 18 15:26:03 <Tantek> DanC, which microformats? any/all that use datetime fields.
Aug 18 15:26:36 <DanC> hard to give useful advice, then.
Aug 18 15:26:58 <DanC> I expect they'll use datetime fields for different things that have different
cost/benefit trade-offs
Aug 18 15:27:26 <DanC> do you know of any particular differences that matter to anybody?
Aug 18 15:56:43 <KragenSitaker> RFC3339 suggests -07:00, which seems like an improvement over -0700 anyway
Aug 18 15:56:49 <Tantek> Kragen, agreed
Aug 18 15:57:01 <Tantek> RFC3339 is certainly preferable to the ISO8601 subset in iCalendar
Aug 18 16:05:57 <DanC> Tantek's right, Kragen; iCalendar looks like it solves the local timezone
problem but doesn't.
Aug 18 16:06:14 <DanC> and it's true that there's no standard solution to the local timezone problem
Aug 18 16:06:39 <Tantek> so instead of appearing to solve the problem but not solving it, we chose to
provide the ability to *approximate* the local timezone using e.g. "-07:00"
Aug 18 16:06:49 <DanC> the simplest thing is to have people use Z time in hCalendar. But I gather
that's unacceptably unusable?
Aug 18 16:07:35 <Tantek> DanC, yes, the simplest thing is to have everyone use UTC Z
Aug 18 16:07:38 <Tantek> However
Aug 18 16:07:50 <Tantek> it is not *nearly* as usuable/verifiable
Aug 18 16:07:55 <Tantek> as -07:00 etc.
Aug 18 16:08:02 <Tantek> hence the decision to go with the latter
Aug 18 16:08:12 <Tantek> some degree of human verifiability is important here
Aug 18 16:14:21 <Tantek> DanC, my perception is that RFC3339 is a subset
Aug 18 16:17:00 <DanC> time-numoffset = ("+" / "-") time-hour ":" time-minute
Aug 18 16:17:34 <DanC> ok, then I can't see any differences. (modulo recent leap seconds issues that
may affect xsd:dateTime )
Aug 18 16:18:07 <Tantek> would be interesting to know why Atom 1.0 chose RFC3339 over xsd:dateTime
Aug 18 16:18:21 <Tantek> if there was a "real" reason or if it was arbitrary / coin-flip.
</pre>

Here's an exhaustive [http://www.imc.org/atom-syntax/mail-archive/msg13103.html comparison] from ndw. I think xsd:dateTime also allows unqualified local times, while RFC3339 allows only UTC with no known timezone (-00:00). In the end, Atompub followed the advice of [http://www.imc.org/atom-syntax/mail-archive/msg13244.html Sam Ruby] and [http://www.imc.org/atom-syntax/mail-archive/msg13248.html Scott Hollenbeck], our area director. Atom dates make some additional restrictions on RFC3339, such as uppercase T and Z characters for compatibility with xsd:dateTime, RFC3339, W3C-DTF, and ISO8601. --[http://franklinmint.fm Robert Sayre]

<pre>
Aug 18 16:18:43 <KragenSitaker> rfc3339 is pretty short.
Aug 18 16:19:36 <Tantek> DanC, BTW, which came first? REC for xsd:dateTime or RFC3339?
Aug 18 16:19:50 <DanC> RFC3339 is dated July 2002 ...
Aug 18 16:19:54 <KragenSitaker> Right --- and you might be able to understand xsd:dateTime without
reading all of xml schema, you wouldn't be confident of it
Aug 18 16:20:25 <DanC> W3C Recommendation 28 October 2004 ... but that's 2nd ed...
Aug 18 16:20:47 <DanC> W3C Recommendation 02 May 2001
Aug 18 16:22:10 <DanC> I don't see a BNF in http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime ...
Aug 18 16:22:43 <KragenSitaker> yeah, appendix D of the current xml schema datatypes document seems
a little scanty, actually
Aug 18 16:23:28 <DanC> ah... 2nd ed of http://www.w3.org/TR/xmlschema-2/#date is much more
explicit about syntax.
Aug 18 16:23:30 <KragenSitaker> it's 1100 words but still doesn't give any examples
Aug 18 16:23:35 <DanC> still, it's given in prose and not BNF
Aug 18 16:24:17 <KragenSitaker> sections 3.2.9 through 3.2.14 seem to be the relevant ones around #date
Aug 18 16:24:29 <KragenSitaker> which is another 2200 words
Aug 18 16:24:42 <DanC> wow... they changed the canonical form of date from always-Z to
timezone-allowed between 1st edition and 2nd edition
Aug 18 16:25:01 <Tantek> Kragen, DanC, these are very good analyses
Aug 18 16:25:21 <Tantek> could I ask you to summarize the pros/cons for each in a new section at
end of http://microformats.org/wiki/datetime-design-pattern
Aug 18 16:25:22 <Tantek> ?
Aug 18 16:25:58 <KragenSitaker> rfc 3339 is 4000 words, excluding the last two pages of boilerplate.
Aug 18 16:26:31 <KragenSitaker> so it's actually longer than the datetime-relevant parts of XSD but it
seems much more rigorous and clear
Aug 18 16:28:37 <DanC> my advice is: normatively cite both, and claim they specify the same
syntax, and let anybody who discovers otherwise send you a bug report
with a test case
Aug 18 16:29:12 <KragenSitaker> danc: nice hack
</pre>

The RFC3339 has a mandatory TIME portion of the DATE-TIME. Some vCard/iCalendar DATE-TIME stamps can omit the TIME. For instance, DTSTART, if that is a full day event, then you can omit the time. BDAY in vCard can be respresented by only a DATE. I like the idea of restricting the possible date formats, but i think that TIME should be optional, which it isn't in RFC3339. - [http://suda.co.uk/ brian suda]

RFC 3339 allows lowercase 't' and 'z' while XSD doesn't. Specifying RFC 3339 plus 'T' and 'Z' MUST be caps will make them the same. - [http://bitworking.org Joe Gregorio]

---

A few questions: asked by [[User:CharlesBelov|CharlesBelov]] 16:57, 24 Apr 2007 (PDT), answered by [[User:JamesCraig|JamesCraig]] on 15:58, 5 Jul 2007 (PDT).

# Would it make more sense for documenting the alternative codings pitting the abbr tag vs. other tags to be on this page? ''Answer: That documentation should go on the [[assistive-technology-abbr-results]] page.''
# Would using the title attribute of the abbr tag to encode the machine-readable date in fact cause a failure of WCAG 2.0 Accessibility? What about USA Section 508? It does appear to violate Technique for WCAG 2.0 [http://www.w3.org/TR/WCAG20-TECHS/#H28 H28: Providing definitions for abbreviations by using the abbr and acronym elements], although that is a supporting document and does not have the force of a guideline. ''Answer: Yes, it appears that is in violation of WCAG, 508, et al, so alternatives are being discussed on the [[assistive-technology-abbr-results]] page.''
# In order to maintain accessibility, would it make sense to enclose the machine-readable date in a span with a style of "display:none" instead of using the abbr tag? ''Answer: please refer to and add any suggestions to [[assistive-technology-abbr-results]].''
# For that matter, wouldn't you want to style such an abbr tag with text-decoration:none to hide that an abbr tag was used? Otherwise, visitors might cursor over the time, see the machine time, and be annoyed that their time was wasted or else be confused. And I don't think you can suppress the title from coming up if the human-readable time was inadvertently hovered. ''Answer: Microformats should not rely on CSS in order to work properly, but again, that discussion can be found here: [[assistive-technology-abbr-results]].''

== Code ==
The following regular expression (parsed VERBOSE) should break apart a datetime and cover many lightly broken cases seen in the wild. This has been tested under Python.

<pre><nowiki>
^
(?P<year>\d\d\d\d)
([-])?(?P<month>\d\d)
([-])?(?P<day>\d\d)
(
(T|\s+)
(?P<hour>\d\d)
(
([:])?(?P<minute>\d\d)
(
([:])?(?P<second>\d\d)
(
([.])?(?P<fraction>\d+)
)?
)?
)?
)?
(
(?P<tzzulu>Z)
|
(?P<tzoffset>[-+])
(?P<tzhour>\d\d)
([:])?(?P<tzminute>\d\d)
)?
$
</nowiki></pre>

== Other Proposals ==

=== strtime instructions as class names ===

Proposal by DavidLaban (alsuren on freenode) on 8 Jun 2008
It might be possible to have a slightly more readable/extensible/elegant format:
<pre><nowiki>
 16 March 1987 
</nowiki></pre>
Notes:
# Underscores are used to replace whitespace, because otherwise the the formatting string will be split into an unordered set of class attributes by many parsers (thanks go to bogdanlazarsb and gsnedders on irc for explaining this to me).
# Some subset of the placeholders should be chosen from those which are supported by both python http://docs.python.org/lib/module-time.html and php http://uk3.php.net/manual/en/function.strftime.php
# A name for the class should be decided upon. strtime might not be the best name.
# Measures should be taken to avoid the format string accidentally conflicting with other valid classes (In the above example, I have prefixed it with the string "format:")
# It might be sensible (when parsing) to strip excess whitespace from the format string and contents. This is not done in this example.
# Example python code follows.

<pre><nowiki>
date = (1987,03,16,0,0,0,0,0,0)
format = " %d %B %Y "
# To encode:
classes = ["strtime"]
encoded_format = "format:" + format.replace(' ', '_')
classes.append(encoded_format)
content = time.strftime(format, birthday)
# ... dump classes and content into your document however you want

# To decode (assuming that you have managed to extract class and format from the document already):
if "strtime" in classes:
possible_formats = [ item for item in classes if item.startswith('format:') ]
assert len(possible_formats) == 1
format = possible_formats[0].strip('format:').replace('_', ' ')
date = time.strptime(content, format)
</nowiki></pre>

==== problems with strtime proposal ====

# Possible abuse of the class attribute. microformats limit the use of the class attribute to marking up additional semantics about the data, not for (potentially) arbitrary processing/programming instructions
#* HTML 4.01 Recommendation [http://www.w3.org/TR/REC-html40/struct/global.html#adef-class defines] the <code>class</code> attribute as being "for general purpose processing by user agents". [[User:TobyInk|TobyInk]] 13:21, 8 Jun 2008 (PDT)
# Requires authors to think like programmers. The larger problem is that the proposal asks web authors to think like programmers, which severely limits the number of web authors which will be able to use the technique, since the vast majority of web authors are ''not'' programmers and have never heard of "strtime", whereas most authors (even people) on the web have seen dates like 2005-06-20 and easily understand what they mean.

In general, any publishing method that requires the author to think like a programmer is a non-starter. It is a much more of a barrier than simply using ISO8601/RFC3339, and that barrier is a far worse tradeoff than the duplication / DRY violation compromise.
[[User:Tantek|Tantek]] 09:52, 8 Jun 2008 (PDT)

* Another problem: if %A/%a/%B/%b are allowed, this raises potential problems with internationalisation. Will parsers be required to understand the names and abbreviations for days and months in potentially hundreds of different languages? [[User:TobyInk|TobyInk]] 14:09, 8 Jun 2008 (PDT)

=== Machine-data in class===
The BBC ([http://microformats.org/discuss/mail/microformats-dev/2008-June/000552.html uf-dev archive, 20/06/08, "Using class for non-human data"]) has proposed as an alternative to the empty span and title solution to use the class name in the following way:
<pre><nowiki>
10 o'clock on the 10th
</nowiki></pre>
Pros:
* Allows data to be represented in a "non-harmful" way. Will not be read aloud by screenreaders or seen as tooltips.
* Minimises mark-up used.
* Arguably more semantic than use of "title" attribute for non-human data.

Cons:
* data in the class attribute has already been discussed numerous times in the mailing list over the years and rejected and documented as an [[anti-pattern]] - captured [http://microformats.org/wiki?title=anti-patterns&diff=24271&oldid=24270 on the wiki this past January 2008].
* Possible misuse of class attribute, although as noted previously, the HTML spec states "for general purpose processing by user agents".
* The class attribute has been adopted by the broader web design community to "subclass" element semantics, and to layer additional semantics. To date, microformats has followed this existing practice developed by modern web designers ("paving the cow-paths"). This use of class for data is outside all current practices.

Discussion:
* This proposal smells icky, but I can't quite put my finger on why. Considered objectively, it does seem to be the least harmful solution proposed so far. [[User:TobyInk|TobyInk]] 06:06, 21 Jun 2008 (PDT)
* I really like it, especially given the HTML4 spec gives this as an IMO perfectly valid use (on both id and class, with the following examples given in the id section: "identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc."). Clean and simple. [[User:Dracos|Dracos]] 03:53, 23 Jun 2008 (PDT)
* I suggest dropping the redundant 'data-' prefix, unless someone can suggest a feasible case with two time-stamps requiring different prefixes. The proposal then becomes [http://www.robertnyman.com/2008/04/28/do-we-really-need-microformats/#comment-263408 one I've made before] [[User:AshSearle|AshSearle]]
** Valid class names cannot begin with a number, so a date needs some sort of letter prefix. It's sensible to make this prefix meaningful and reusable in some way. [[User:Phae|Phae]]
*** They can't in CSS, but they can in (X)HTML. http://examples.tobyinkster.co.uk/numeric-classes.html [[User:TobyInk|TobyInk]] 06:53, 24 Jun 2008 (PDT)
**** Creating classes in HTML that can't be referenced in CSS is a bad thing. Using colons and starting with numbers fall into that category. http://www.w3.org/TR/CSS21/syndata.html#characters Also, replacing whitespace with underscores breaks the ISO compatibility, which sorta defeats the whole point of using existing standards. Finally the class names are unordered, so trying to use them in a series is a bad idea. --[[User:Atamido|Atamido]] 11:43, 30 Jul 2008 (PDT)
***** They can be referenced in CSS, just not using the "dot notation". They can be referenced using attribute selectors, which are supported in all modern browsers (but not IE6). [[User:TobyInk|TobyInk]] 13:21, 30 Jul 2008 (PDT)
****** They could also be referenced by escaping the characters, but that still excludes >99% of current use cases. I'd wager that most authors don't even know about the limitations and would run into issues in implementation. --[[User:Atamido|Atamido]] 13:47, 30 Jul 2008 (PDT)
***** I don't think the proposal relies on classes being in any particular order. Even if it did, I don't know of any DOM implementations which do not provide the contents of the class attribute in their original order. [[User:TobyInk|TobyInk]] 13:21, 30 Jul 2008 (PDT)
** Not to advocate too strongly for designing for parsers (generally a bad idea), *but* having a 'data-' prefix on a class name would make identifying data orders of magnitude easier for parsing. Otherwise, how do we know what's data and what's just another class name for some other purpose? [[User:DrewMcLellan|Drew]]
** A 'data-' prefix would help authors tasked with maintaining or reviewing a page to understand the purpose of a class name that may have been applied by another author. The data prefix communicates very simply that the class name is precisely that, data. Therefore the value is less likely to be accidentally removed or changed, making for a more robust design. [[User:DrewMcLellan|Drew]]
*** I concede - regardless of whether it's valid (X)HTML / CSS - a prefix is needed to distinguish data values from genuine content. ISO 8601 allows date-time to be as simple as "2004", which could easily be misinterpreted. e.g. if a CMS outputs product model numbers into the class attribute for some other purpose. --[[User:AshSearle|AshSearle]] 01:42, 25 Jun 2008 (PDT)
*** Using <code>data-</code> as the prefix here is undesirable, as it now conflicts with HTML5's proposed <code>-data</code> prefix on attributes. It's undesirable to set ourselves up for future confusion with our own conflicting specification of ‘a data prefix’. A different prefix should be considered. See: [http://www.w3.org/html/wg/html5/#custom HTML5 Editors Draft: Embedding Custom Non-Visible Data] —[[User:BenWard|BenWard]] 07:34, 16 Jul 2008 (PDT)
* -1 [[User:Tantek|Tantek]]. I'm vehemently opposed to putting data in the class attribute. We ''must'' find better alternatives. We must not go down the path of invisible (dark) (meta)data - IMHO that [[principle]] is inviolable for microformats.
** [[User:JakeArchibald|JakeArchibald]] If you're so opposed, it'd be useful to see some justification.
*** See above cons. Already discussed/rejected many times in the history of microformats discussions. In short, quit wasting time on old ground. Abuses class attribute, or if you prefer, introduces a *new* use of the class attribute, unlike microformats to-date which have simply made use of a well established semantic of the class attribute. And worst of all, completely violates the visible data [[principle]]. Rejectable on that alone.
**** The fact that something has been discussed and rejected before is not sufficient grounds for dismissing it out of hand once additional research and thinking has taken place. The <abbr> datetime pattern arguably abused the title attribute and introduced a new use of the title attribute. In the example given (<code><nowiki>10 o'clock on the 10th</nowiki></code>), the data is presented as "10 o'clock on the 10th" - very visible. Yes, of course, it's possible to abuse this proposed pattern, and hide the data, but the same can be said of the abbr pattern or even the class pattern given CSS's display:none property. Experience shows that in most cases, people ''won't'' abuse the pattern to hide data, as they actually ''want'' to show the data on their pages. [[User:TobyInk|TobyInk]] 13:52, 24 Jun 2008 (PDT)
**** It's not an abuse of the class attribute according to the HTML spec. as I read it. Whereas using title for non-human data is (the spec says audio agents may read it aloud, for example). If it's a new use, it's one the writers of HTML4 considered, so it wasn't new to them. [[User:Dracos|Dracos]] 03:38, 25 Jun 2008 (PDT)
** Relevant princeples are 'humans first, machines second', and 'visible data is ''better'''. These are ''preferences'', not inviolable principles. Besides, the existing datetime spec doesn't adhere to these principles anyway: prioritising humans first, <code><nowiki>let's discuss this at the next meeting</nowiki></code> should be marked up as <code><nowiki>let's discuss this at the <abbr title="28th June 2008 at 3:15pm">next meeting</nowiki></code>. There's a conflict between human- and machine-readable dates. It makes more sense to 'hide' the machine-readable data in the only attribute available to us: <code>class</code>. --[[User:AshSearle|AshSearle]] 03:02, 25 Jun 2008 (PDT)
*** Indeed - by their nature, ''principles'' are ''generalisations'', and while broadly useful, usually have exceptions. After experience, the microformats community is beginning to see some of these. Human vs machine dates is the one gathering the most interest at the moment, largely thanks to <abbr class="help" style="border-bottom:1px dotted" title="the Web Standards Project">WaSP</abbr> and auntie, but I think other properties which will probably emerge as exceptions to the general microformats principles are hReview's <code>type</code> property, and the its namesake subproperty for hCard's <code>tel</code>, <code>email</code> and <code>adr</code> (and <code>label</code>?) properties. [[User:TobyInk|TobyInk]] 12:51, 25 Jun 2008 (PDT)

==== Experimental Parser Support ====

[http://buzzword.org.uk/cognition/ Cognition 0.1 alpha 10] will include experimental support for this pattern, and the [http://srv.buzzword.org.uk Cognition web service] already does. Notes:
* Support is ''opt-in''. Publishers must explicitly request support for the pattern, by including a [[profile-uris|profile URI]] of <code><nowiki>http://purl.org/uF/pattern-data-class/1</nowiki></code> in their document head.
* Support is not limited to date-time properties, but any microformat properties.
* data-X classes must use percent-encoding to encode spaces and other characters not allowed in class names.
* The data-X class must be found on the same element as the microformat property class. That is, you cannot use: <pre><nowiki>10 o'clock</nowiki></pre>
<ul><li>Multiple data-X classes may occur on the same element. When these are found, the longest string is used. This allows for: <pre><nowiki>The 10th</nowiki></pre> which may be useful for styling or other non-microformat purposes.</li>
<li>Can be combined with value excerpting. e.g. <pre><nowiki>

The concert will be held on
the 4th of August
starting at
7:30pm precisely.

</nowiki></pre></li></ul>

=== date and time separation using value excerption ===

==== summary ====
By specifying a more precise parsing of the use of "value" excerption inside all datetime properties (e.g. dtstart, dtend, published, updated etc.), dates and times can be marked up separately, thus reducing/minimizing (and potentially eliminating) the readability issues that come with compound ISO8601 datetimes.

==== introductory example ====
The sentence:

<pre><nowiki>
The weekly dinner is tonight at 6:30pm.
</nowiki></pre>

would be marked up as:

<pre><nowiki>
The weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
at <abbr class="value" title="18:30">6:30pm</abbr>.
</nowiki></pre>

==== advantages ====
* re-uses the readable [[abbr-date-pattern]]
* identifies a similarly readable abbr-time-pattern.
* minimizes DRY violation distance, keeps machine data on exactly the same element as the respective human data
** even better than [[abbr-datetime-pattern]] does, which, in practice from experience often required specifying the date in machine readable form on the human readable time (separate from the human readable date).
* introduces no new class names - [[principle]] of minimal invention
* introduces no new use of the class attribute - principle of minimal invention again
* introduces no new syntax ([[datetime-design-pattern#problems_with_strtime_proposal|see above]] about any publishing method that requires the author to think like a programmer being a non-starter, and introducing new syntax almost always requires authors to think like programmers).
* and most importantly, introduces no dark data.

==== issues ====
Some potential issues were raised in IRC, and it helps to document/resolve them so that they are not brought up repeatedly.
* [[http://rbach.priv.at/Microformats/IRC/2008-06-24#T163114 Does this sufficiently address the concerns raised with the current use of abbr-pattern?]]
*# The [[abbr-date-pattern]], as documented and explained by [[User:Adactio|Jeremy Keith]] is just fine (in contrast to the [[abbr-datetime-pattern]]).
*# Similar to the [[abbr-date-pattern]], this proposal implies/introduces the abbr-time-pattern, which is similarly acceptable.
*# In addition, as long there is incremental improvement, we are making progress. It is more important to take small steps that we know will help some things, rather than try to take a big step that is more risky in the attempt to help more but may not actually do so (as most big changes don't), therefore "sufficiently" is a flawed way of evaluating incremental fixes.
* Exposes data through tooltips. Separating into 2008-06-07 and 18:03 improves the ability for humans to consume the data, but still exposes data through tooltips and speech in formats that the publisher did not choose to use. --[[User:BenWard|BenWard]] 04:52, 25 Jun 2008 (PDT)
*# This is a feature, not a bug. By making the duplicated data at least *somewhat* visible (rather than fully invisible), effective data quality is increased due to the fact that the probability of the ISO8601 and locale-specific data getting out-of-sync is reduced because of the increased visibility (and therefore the increased inspectability and more eye-balls looking at/for problems effect).
*# Workaround: if a site publisher wishes to customize the presentation of tooltips, they can do so with a nested span with title.
*#* That proposes extraneous mark-up maintain some publisher's wish not to have a tool-tip in the first place. I object to a microformat pattern requiring an immediate work-around to meet publisher's desires. It goes against ‘Humans first…’. --[[User:BenWard|BenWard]] 09:09, 30 Jun 2008 (PDT)
*#*# Additional markup has nothing to do with "Humans first".
*#*# Additional markup to work-around minor issues (e.g. CSS, cross-browser compatibility, etc.) is a well accepted modern web design practice. It's not ideal, but it is both accepted and widely practiced. With the use of <code></code> and <code><div></code> elements, it's also semantically neutral, therefore not a problem from that perspective either.
*#*# Finally, it should not be our goal to try to satisfy *every* publisher, for that would make every microformat beholden to every publisher and contort the design of microformats in really poor ways. We must accept that not all publishers will adopt all microformats and that is ok. Our goal to incrementally increase the number of publishers that adopt microformats, not to try to satisfy each and every one.
* Semantic misuses of ABBR. That ‘tonight’ is ever a textual, human abbreviation of ‘2008-06-24’ is not accepted.
*# Semantic stretch not misuse. It is a semantic abbreviation rather than a purely syntactical (character shortening) abbreviation, but it is an abbreviation in context nonetheless. Though this may stretch what may be commonly expected as an "abbreviation", the HTML4 spec does seem to allow some flexibility here ([http://www.w3.org/TR/html401/struct/text.html#h-9.2.1 HTML 4.01 9.2.1 Phrase elements]).
* Maintaining proper sentences with the expanded form. It is not always possible to use this mark-up and maintain proper sentences with the expanded form. e.g. <code>it's my <abbr class="bday" title="2005-06-20">birthday today</abbr>!</code> becomes ‘it's my 2005-06-20!’. And thus audio rendition of such titles can be nonsensical - "The weekly dinner is two thousand and eight dash zero six dash twenty four at eighteen thirty."
*# This can and should be addressed by improving authoring examples so that practices improve with experience.
* Publishing practices and desires show us that authors are not willing to compromise the semantics of abbr. [[User:Phae|Phae]] 04:30, 27 Jun 2008 (PDT)
*# Without specific citations of which authors and what specific issues they have, we are unable to address their issues.
*# See also above - not our goal to satisfy *every* publisher, but rather to incrementally satisfy more and more. We must accept that there may be some authors we are unable to satisfy in the immediate/short-term.
* [[http://rbach.priv.at/Microformats/IRC/2008-06-24#T163435 That's getting pretty complicated]]
** Much less complicated than inventing yet another syntax ( " { ... } " ???? ) that web authors would have to learn.
*** But it's all in one place, rather than spreading it out.
**** The spreading it out is what current content publishing practices do already! It is much more important to map the machine data as close to the existing publishing practice as possible, than to try to "put it all in one place". The "put it all in one place" way of thinking is why people ended up sticking so much invisible metadata in the head of the document, which we know fails.

==== content requirements ====
Some requirements which enhance both human readability, ''and'' machine parsability (best of both) :
* date value excerpts MUST use hyphen separators. E.g. 2008-06-24. Not ok:20080624.
* time value excerpts MUST use colon separators (seconds optional, implied :00 if absent). E.g. 18:30 or 18:30:00. Not ok:183000.
* timezone value excerpts MUST use leading plus or minus and NO colon separator. E.g. -0700. Not ok:-07:00.

==== derivation ====
It's important to document the derivation/background of a brainstorm/proposal as it allows others to see some of the thinking that went into it, and avoid having to rediscuss alternatives already considered, and helps provide understanding as to why aspects of the design are as they are.
===== example with datetime =====
Here is a short code example:
<pre><nowiki>
the weekly dinner is tonight at 2008-06-24T18:30
</nowiki></pre>
===== example with abbr datetime =====
However that's not the easiest to read, nor do most people publish that as human visible text, so per the abbr-datetime pattern:
<pre><nowiki>
the weekly dinner is tonight at <abbr class="dtstart" title="2008-06-24T18:30">6:30pm</abbr>
</nowiki></pre>

which has raised two issues:
# When "2008-06-24T18:30" is inspected by a human reading a tooltip, or spoken by a screen reader, it's not the most understandable thing (precise citation needed, perhaps an mp3 with screen reader used version info).
# There is a non-local violation of DRY (which IMHO is a worse problem, as it leads to worse data quality -[[User:Tantek|Tantek]]). That is, the "date" information is now not only in the text twice (as it was before), but those two instances of the date information are not on the same element, which makes it worse. That is, "tonight" is in the prose, ''outside'' of the element with the precise date "2008-06-24".

In analysis of examples of event information on the web, the date and time are often published in separate elements, often for display purposes.

Thus it is this existing content publishing practice which leads to this brainstorm proposal, to essentially to introduce a date and time value excerption longhand.

(Initially [http://rbach.priv.at/Microformats/IRC/2008-06-21#T181634 Tantek's idea that he bounced off Jeremy Keith] ([http://rbach.priv.at/Microformats/IRC/2008-06-24#T124652 similar idea conceived by Drew independently]) was to [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161819 introduce new classes "datevalue", "timevalue"] and "tzvalue" for this purpose, but [http://rbach.priv.at/Microformats/IRC/2008-06-24#T171603 Bob Jonkman pointed out] that HTML5's time parsing algorithm enables a single <nowiki><time></nowiki> element to contain dates or times (with or without timezone) without having to explicitly say whether the value contains dates or times (with or without timezone). [http://rbach.priv.at/Microformats/IRC/2008-06-24#T171723 Bob then proposed] that thus all was needed was a single new "datetime" class name. This was the key realization that allowed minimal invention. Tantek pointed out that since from the type of property we already know it is a datetime, [http://rbach.priv.at/Microformats/IRC/2008-06-24#T171835 there was no need for even one new class name], that we could simply re-use "value" excerption, and simply more precisely specify the semantics/parsing in the case of datetime properties.)

===== example with new date and time value excerpts =====
Thus we markup the date and time separately, as value excerpts, using the [[abbr-date-pattern]] and an implied parallel abbr-time-pattern:

<pre><nowiki>
The weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
at <abbr class="value" title="18:30">6:30pm</abbr>.
</nowiki></pre>

===== separate subtrees =====
The proposal also allows setting the date and time in separate element subtrees as well, which may be necessary for some document structures:

<pre><nowiki>
the weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
at <abbr class="value" title="18:30">6:30pm</abbr>.
</nowiki></pre>

Note the two instances of dtstart, one of which sets the date for the dtstart, and the other of which sets the time.

The idea being, when a parser sees a datetime property (e.g. dtstart) with a value excerpt, that it only "set" the component of its full value that is specified by the value excerpt (e.g. the date), and that if lacking a complete datetime, it continue to parse additional instances of that datetime property for the remaining component(s) (e.g. the time).

Of course this only works for singular properties, but fortunately all instances of datetime properties so far are singular, so this works.
* hCard's <code>rev</code> is plural. [[User:TobyInk|TobyInk]]
** can someone give a reference to this being the case? The RFC says "The value distinguishes the current revision of the information in this vCard for other renditions of the information." Does it make sense to have multiple REV dates in a single vCard?
*** The RFC is ambiguous as usual, but a contact card could conceivably have had several changes made to it, with a <code>rev</code> for each. ("Change logs" are fairly common on the web.) The [[hcard|hCard spec]] is fairly specific about which properties are [[hcard#Singular_vs._Plural_Properties|singular]] and which are not, and <code>rev</code> is not included in the list of singular properties.

===== reusing date data for multiple datetime properties =====
This also provides a *very* convenient way to re-use the same date information for start and end, e.g. expanding the example:

<pre><nowiki>
the weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
from <abbr class="value" title="18:30">6:30</abbr> -
<abbr class="value" title="20:30">8:30pm</abbr>.
</nowiki></pre>

Note what just happened. we just eliminated another duplication of date information by reusing the start *date* information for the end *date* information and *only* specifying the end *time* information separately for the two properties.

Reducing the duplication (or triplication) of such data helps to reduce the chances of (even inadvertent) data corruption/drift/divergence among any duplicates.

===== time zones =====
There are a few choices for timezones.
# Simply include the time zone information as part of the time "value". E.g. <code><nowiki><abbr class="value" title="18:30-0700">6:30pm</abbr></nowiki></code>
# Or use another value excerpt for the timezone (was: <del>introduce the class name "tzvalue"</del>) E.g. <code><nowiki><abbr class="value" title="18:30">6:30pm</abbr> <abbr class="value" title="-0700">PDT</abbr></nowiki></code>
# Or allow both and let web authors decide. This is the current leaning.
#* if web authors want to specify timezone as part of the time (first example above), they can,
#* or if web authors visibly publish the timezone separately (second example above), then they can mark that up.
#* or if web authors wish to omit timezone information, they can do so as well, as most do today. In practice this works fine, as it creates a "floating" time which works fine in far more than the 80/20.

(more to come, documenting [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161740 from IRC logs])

==== discussion ====
Opening up a discussion section even though documentation [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161740 from IRC logs] is still in progress. :)

* regarding the [[datetime-design-pattern#advantages|advantage]] of "and most importantly, introduces no dark data."
** "Dark data" is sometimes what publishers *want* to publish. To use the example of TV schedules which kick started the renewed discussion in this area, publishers will often not want to display the date. For instance, if a page entitled "Tomorrow's TV" and containing 300 different programmes marked up with <code>dtstart</code>, it is superfluous to explicitly display the date for each one. With this proposed solution the [[include|include pattern]] could be used to include the date into each vevent, but a visible link to the date on each programme would simply be confusing. Sometimes it just makes sense to hide some of the information you're publishing as a microformat - because the information you want to make explicit to parsers can be inferred from context by humans, or is more appropriately displayed at a different level of granularity for machines and humans. [[User:TobyInk|TobyInk]] 14:26, 24 Jun 2008 (PDT)
*** It doesn't matter whether publishers *want* to publish dark data or not. Invisible data always leads to poorer quality data. Publishers publish all kinds of invisible metadata in the heads of documents etc. because they want to, but their desire doesn't stop the data from becoming obsolete, diverging from the actual visible data etc. The quality of the data matters more than any publishers wish(es) of publishing in a specific format, or in a hidden way. In the example you gave, using the include pattern in that way would not result in any visible links, but merely empty include anchors. It never makes any sense to actually hide "some of the information you're publishing as a microformat", because historically that always results in some loss of data quality over time and thus the microformats [[principle]] of visible data instead of invisible metadata. [[User:Tantek|Tantek]] 14:32, 24 Jun 2008 (PDT)
**** All microformats hide ''some'' data. In the example <code><nowiki>01632 960123</nowiki></code>, the information that the long string of numbers represents a telephone number is invisible. And making it visible (<code><nowiki>Tel: 01632 960123</nowiki></code>) violates DRY. It's just a matter of where to draw the line.
***** That statement makes the mistake of conflating *type* data and *content* data. "tel" is not content data, just as <nowiki></nowiki> is not content data. It's markup, indicating the type of the data. Markup (type data) being invisible to the user has worked just fine. Content (content data) being invisible to the user is the problem of dark data. Or rather, if you think that everything is data, then you really should be spending time developing in a system that is built on that assumption, e.g. RDF, rather than microformats, which are built on HTML, and the clear separation of type of data (HTML elements, microformats properties) and content data (inner text, text attribute values).
****** My point is that there isn't a ''distinction'' between the two, but a ''continuum''. The choice of where to draw the line is never a clear one and always somewhat arbitrary. The vCard standard could quite easily have ended up with separate "TEL", "FAX" and "CELL" properties, in which case hCard would have ended up with <code><nowiki><foo class="tel"></nowiki></code>, <code><nowiki><bar class="fax"></nowiki></code> and <code><nowiki><baz class="cell"></nowiki></code>. Going the other way, they could have stored e-mail addresses as mailto: URLs, and then hCard would have <code><nowiki><a class="url" href="mailto:quux@example.com"></nowiki></code>. They chose the way they did, and as a result in hCard the distinction between a mailto: URI and an http: URI is largely invisible (in most circumstances only obvious by looking at the status bar when hovering), but the distinction between a telephone number and a fax number is visible. But that wasn't the only possible (nor the only reasonable) outcome.

=== HTML 5 <code><time></code> Element ===

[http://microformats.org/wiki/hcalendar-issues#html5-time-element See hCalendar issues]

=== Plain Old English alternative to ISO date ===

Example (in English):

<pre>
<abbr title="January 25th, 2008" class="dstart" lang="en-us">1/25</abbr>
</pre>

<pre>
January 25th, 2008
</pre>

If <code>lang="en-us"</code>, the format of the date used in the <code>title</code> attribute must conform to [http://www.ego4u.com/en/cram-up/vocabulary/date/written dates writing rules in American English].

Example (in French):

<pre>
<abbr title="25 Janvier 2008" class="dstart" lang="fr">25/1</abbr>
</pre>

If <code>lang="fr"</code>, the format of the date used in the <code>title</code> attribute must conform to date writing rules in French.

====Benefits====

* Human-hearable: should work nicely with screen readers (to be tested).
* Human-readable
* Compliance with semantics of abbr.
* Very easy to use by HTML human authors.
* DRY compliant if HTML human authors are willing to write in correct English

====Discussion====

* Locale-specific parsing logic.
* Not all cultures use the same calendar — Dan Brickley
* There are situations where markup clues used for localisation might be misleading, such as people using microformats in a post on a site they do not themselves run that may even be in a different country. (a shared blogging site that allows html tags in posts would be a good example here) — Michael MD
** Couldn't the person or tool adding the microformat annotation also add a lang attribute at the same time? — Benjamin Hawkes-Lewis
* Cognition already supports this as a last ditch attempt at parsing dates - but I wouldn't recommend it get adopted widely. It's too unreliable; too much work to deal with internationalisation; too much work full-stop in languages that don't provide a handy library that takes care of most of the work. — [[User:TobyInk]]
** I don't think we need to support all locales at once. I don't know in how many written languages BBC publishes in, but it might be that supporting en-uk and en-us might be enough for a start. Also, one can imagine that Microformats tools could focus on the most common written languages and then expose hooks for others to implement support for other locales. — Guillaume Lebleu
** What are our priorities? Making programmers' life easier or making content authors and content readers' life easier? — Guillaume Lebleu
*** In Australia dd/mm/yyyy is commonly used, but a significant minority of sites in Australia use US-style mm/dd/yyyy because it is the default setting in their CMS. How would a parser be able to tell which part is the day and which is the month? Getting it wrong would be worse than not getting it at all! Until the use of ambiguous formats can be ''wiped out'' we ''will'' need a version for machines! — Michael MD
*** problem which hasn't been raised with regards to this proposal is that even though you are proposing a fixed date format, because it *looks* like natural language, authors will assume that it *is* natural language, and simply start including dates in whatever format they like. Then you get an NLP "arms race" between publishers and parsers. If you don't believe that that will happen, take a look at what happened with RFC 822 dates, which are simply a mess. — [[User:TobyInk]]
**** Very true the more you make the date look like natural language, the less it looks like a fixed format. I really don't want us to get involved in any form of NLP, it just would not work. I think it was Mike who said that dates have to be parsed correctly, no level of error is acceptable. I don't want to travel to an event on the wrong day because a parser got the date wrong — Glenn Jones

====Notes====

* Could work alongside with the existing [[datetime-design-pattern]]: if ISO date parsing fails, try parsing the title as a human-readable plain old English/French/... date according to the locale.

===<code><object></code> element to represent dates===

* Re-raised by George Brocklehurst on June 25th 2008.

The idea was to do something like this:

<pre><code><object data="20050125">January 25</object></code></pre>

* From what Tantek [http://tantek.com/log/2005/01.html said on his blog] , the main reason for not using objects was that they were not well supported in Safari. However, Safari's object support is now much improved: fallbacks are supported and display:inline and intrinsic sizing will work correctly. Safari 2.0.2, which came out in November 2005, was the first version to [http://webkit.org/blog/32/webkit-fixes-in-safari-202-mac-os-x-1043/ contain these improvements]. — George Brocklehurst
* The following appears to be well behaved inline in Safari 2.04 and 3.1.1, Firefox 1, 1.5, 2 and 3, and Opera 7, 8 and 9: <code><object class="dtstart" data="data://20080712"></object></code>. Test case: http://pastie.org/224023 — Ben Ward
** IE 6, 7 and the beta version of IE 8 all visibly render the object element as a small box, similar to the way they would render a missing image: http://georgebrock.com/misc/object-in-ie.png — George Brocklehurst
** Absolute URIs can't start with a number, but relative ones can - and the data attribute is permitted to contain relative URIs. [Don't need to use data:// URI) — Toby A Inkster
* Could also look at <code><object class="dtstart"><param name="value" value="20050125" />January 25</object></code> — Scott Reynen
* 1. The purpose of the <object> element is to allow the browser to run an external application for a non-native data type (e.g., Java applet). See: http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.3. Object is not the right way to go in this case. — Sarven Capadisli

===Individual markup of each date/time component===

A combination of suggestions that originated from this [http://www.mail-archive.com/microformats-discuss@microformats.org/msg10218.html post]

This is suggested as a complementary alternative to datetime-design-pattern, when the use of the pattern is not possible due to accessibility reasons.

suggested class names:
* <code>date</code>
* <code>time</code>
* or maybe <code>datetime</code> ?
* <code>s</code> for seconds
* <code>min</code> for minutes
* <code>hr</code> for hours
* <code>ampm</code> for AM/PM
* <code>tz</code> for timezone. (ex. <code>GMT</code>)
* <code>tzo</code> for timezone offset (ex. <code>-7</code>)
* <code>day</code>
* <code>mo</code> for months
* <code>yr</code> for year

For a complete datetime:

<pre>


October 5, 2004
 at

6PM


</pre>

<code>date</code> maybe not required since <code>dstart</code> IS a <code>date</code>.

For a duration:

<pre>

1:
3:
42

</pre>

'''Issues'''
* the internationalization issue is not addressed, but it is limited to the month of the year.

== See Also ==

* [[Main_Page#Design_Patterns|All microformat design patterns]]
* [[abbr-design-pattern]] is used by [[datetime-design-pattern]]
* [[date-design-pattern]] is a subset of [[datetime-design-pattern]]
* HTML 4.01 definition of <code><[http://www.w3.org/TR/REC-html40/struct/text.html#edef-ABBR abbr]></code> element
* RFC [http://www.faqs.org/rfcs/rfc3339.html 3339]: Date and Time on the Internet: Timestamps
* W3C: [http://www.w3.org/TR/NOTE-datetime Note on Datetimes]
* Markus Kuhn: [http://www.cl.cam.ac.uk/~mgk25/iso-time.html A summary of the international standard date and time notation]
* Wikipedia: [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]

datetime-design-pattern

2008-08-06T19:06:47Z

Guillaume Lebleu: added "Individual markup of each date/time component" alternative

<h1> Datetime Design Pattern </h1>
This is a page for exploring a datetime design pattern.

{{TOC-right}}

== Purpose ==
* Use the [[datetime-design-pattern]] to make datetimes that are human readable also formally machine readable.

== Practical Need ==
* This design pattern arose as a result of solving the practical need for human readable dates for [[hcalendar|hCalendar]].

== How to use it ==
* enclose the human-friendly datetime that you want to make machine readable with <code><abbr></code>
* as per the [[class-design-pattern]], add the appropriate <code>class</code> attribute to the <code>abbr</code> element
* add a <code>title</code> attribute to the <code>abbr</code> element with the machine readable [[iso-8601|ISO8601]] datetime or date as the value

==Current uses==

The pattern, which is now available as part of [[hAtom]], [[hcalendar|hCalendar]], [[hcard|hCard]] and [[hreview|hReview]], is:

:<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">Date Time</abbr></pre>

where foo is the semantic classname which is being applied to this date/time, the title of the <abbr> is an ISO 8601 date/time, with an appropriate level of specificity, and "Date Time" is a human-friendly representation of the same date/time.

An alternative, if you are using UTC-based timestamps, would be:

:<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SSZ">Date Time</abbr></pre>

with a single "Z" as per [[iso-8601|ISO 8601]]

Ruby: An easy way to get this format from a DateTime is this:
:<pre>DateTime.now.to_s</pre>

== Profile of ISO8601 ==

Any [[microformat]] using the date-time-design pattern {{should}} use a profile of [[iso-8601|ISO8601]]. There are currently two widely used profiles which {{should}} be reused.

* RFC 3339
* [http://www.w3.org/TR/NOTE-datetime W3C Note on Datetimes]

==Accessibility issues==

Note: Some accessibility issues have been raised([http://www.webstandards.org/2007/04/27/haccessibility/]) with Datetime Design Pattern, and concerns that its use could breach WCAG accessibility guidelines, that are being addressed as part of the [[abbr-design-pattern-issues]] discussion. Possible change recommendations may follow after the accessibility testing is complete. The accessibility concerns are considerably lessened, even eliminated when using the [[date-design-pattern]], a subset of the [[datetime-design-pattern]].

== Discussion ==
This pattern is likely to be highly resuable.

--[[User:RyanKing]]

Can this not be viewed as a microformat in itself?

--[[User:DimitriGlazkov]]

It could, but inventing a microformat for the sake of inventing a microformat is against the microformat principles.
If there is a specific real world problem (and uses cases) that such an elemental microformat would solve, then it would be worth considering.

Until then it is best to keep the <abbr> datetime concept merely as a microformat design pattern, to be used in _actual_ microformats that have a demonstrated practical need.

-- [http://tantek.com/log/ Tantek]

Excerpt from #microformats Aug 18th. Please edit!

<pre>
Aug 18 15:16:14 <Tantek> DanC, what do you think of RFC3339?
Aug 18 15:17:14 <Tantek> ISO8601 subset
Aug 18 15:17:19 <DanC> Date and Time on the Internet: Timestamps http://www.ietf.org/rfc/rfc3339.txt
Aug 18 15:17:30 <DanC> Klyne is a good guy. I wonder if I talked with him about this.
Aug 18 15:17:32 <Tantek> compat with W3C-NOTE-DATETIME
Aug 18 15:17:50 <Tantek> compat with xsd:dateTime
Aug 18 15:17:57 <Tantek> it's a strict intersection subset
Aug 18 15:17:59 <DanC> I consider W3C-NOTE-DATETIME obsoleted by XML Schema datatype-- yeah.. xsd:dateTime
Aug 18 15:18:32 <Tantek> compare/contrast normatively using xsd:dateTime vs. RFC3339
Aug 18 15:18:41 <Tantek> note: Atom 1.0 chose RFC3339
Aug 18 15:18:50 <Tantek> i would like input from the microformats community on this
Aug 18 15:19:27 <DanC> in what context are you evaluating RFC 3339?
Aug 18 15:19:28 <jcgregorio> http://bitworking.org/news/Date_Constructs_in_the_Atom_Syndication_Format
Aug 18 15:21:24 <DanC> which microformat is the question coming from, Tantek ?
Aug 18 15:23:31 <DanC> " The grammar element time-second may have the value "60" at the end of
Aug 18 15:23:31 <DanC> months in which a leap second occurs" The XML Schema WG is in the 27th level of
leap-second-hell for the past few months, I gather.
Aug 18 15:24:21 <DanC> yeah... here's the scary bit: " Leap seconds cannot be predicted far into the
future. The
Aug 18 15:24:21 <DanC> International Earth Rotation Service publishes bulletins [IERS] that
Aug 18 15:24:21 <DanC> announce leap seconds with a few weeks' warning."
Aug 18 15:26:03 <Tantek> DanC, which microformats? any/all that use datetime fields.
Aug 18 15:26:36 <DanC> hard to give useful advice, then.
Aug 18 15:26:58 <DanC> I expect they'll use datetime fields for different things that have different
cost/benefit trade-offs
Aug 18 15:27:26 <DanC> do you know of any particular differences that matter to anybody?
Aug 18 15:56:43 <KragenSitaker> RFC3339 suggests -07:00, which seems like an improvement over -0700 anyway
Aug 18 15:56:49 <Tantek> Kragen, agreed
Aug 18 15:57:01 <Tantek> RFC3339 is certainly preferable to the ISO8601 subset in iCalendar
Aug 18 16:05:57 <DanC> Tantek's right, Kragen; iCalendar looks like it solves the local timezone
problem but doesn't.
Aug 18 16:06:14 <DanC> and it's true that there's no standard solution to the local timezone problem
Aug 18 16:06:39 <Tantek> so instead of appearing to solve the problem but not solving it, we chose to
provide the ability to *approximate* the local timezone using e.g. "-07:00"
Aug 18 16:06:49 <DanC> the simplest thing is to have people use Z time in hCalendar. But I gather
that's unacceptably unusable?
Aug 18 16:07:35 <Tantek> DanC, yes, the simplest thing is to have everyone use UTC Z
Aug 18 16:07:38 <Tantek> However
Aug 18 16:07:50 <Tantek> it is not *nearly* as usuable/verifiable
Aug 18 16:07:55 <Tantek> as -07:00 etc.
Aug 18 16:08:02 <Tantek> hence the decision to go with the latter
Aug 18 16:08:12 <Tantek> some degree of human verifiability is important here
Aug 18 16:14:21 <Tantek> DanC, my perception is that RFC3339 is a subset
Aug 18 16:17:00 <DanC> time-numoffset = ("+" / "-") time-hour ":" time-minute
Aug 18 16:17:34 <DanC> ok, then I can't see any differences. (modulo recent leap seconds issues that
may affect xsd:dateTime )
Aug 18 16:18:07 <Tantek> would be interesting to know why Atom 1.0 chose RFC3339 over xsd:dateTime
Aug 18 16:18:21 <Tantek> if there was a "real" reason or if it was arbitrary / coin-flip.
</pre>

Here's an exhaustive [http://www.imc.org/atom-syntax/mail-archive/msg13103.html comparison] from ndw. I think xsd:dateTime also allows unqualified local times, while RFC3339 allows only UTC with no known timezone (-00:00). In the end, Atompub followed the advice of [http://www.imc.org/atom-syntax/mail-archive/msg13244.html Sam Ruby] and [http://www.imc.org/atom-syntax/mail-archive/msg13248.html Scott Hollenbeck], our area director. Atom dates make some additional restrictions on RFC3339, such as uppercase T and Z characters for compatibility with xsd:dateTime, RFC3339, W3C-DTF, and ISO8601. --[http://franklinmint.fm Robert Sayre]

<pre>
Aug 18 16:18:43 <KragenSitaker> rfc3339 is pretty short.
Aug 18 16:19:36 <Tantek> DanC, BTW, which came first? REC for xsd:dateTime or RFC3339?
Aug 18 16:19:50 <DanC> RFC3339 is dated July 2002 ...
Aug 18 16:19:54 <KragenSitaker> Right --- and you might be able to understand xsd:dateTime without
reading all of xml schema, you wouldn't be confident of it
Aug 18 16:20:25 <DanC> W3C Recommendation 28 October 2004 ... but that's 2nd ed...
Aug 18 16:20:47 <DanC> W3C Recommendation 02 May 2001
Aug 18 16:22:10 <DanC> I don't see a BNF in http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime ...
Aug 18 16:22:43 <KragenSitaker> yeah, appendix D of the current xml schema datatypes document seems
a little scanty, actually
Aug 18 16:23:28 <DanC> ah... 2nd ed of http://www.w3.org/TR/xmlschema-2/#date is much more
explicit about syntax.
Aug 18 16:23:30 <KragenSitaker> it's 1100 words but still doesn't give any examples
Aug 18 16:23:35 <DanC> still, it's given in prose and not BNF
Aug 18 16:24:17 <KragenSitaker> sections 3.2.9 through 3.2.14 seem to be the relevant ones around #date
Aug 18 16:24:29 <KragenSitaker> which is another 2200 words
Aug 18 16:24:42 <DanC> wow... they changed the canonical form of date from always-Z to
timezone-allowed between 1st edition and 2nd edition
Aug 18 16:25:01 <Tantek> Kragen, DanC, these are very good analyses
Aug 18 16:25:21 <Tantek> could I ask you to summarize the pros/cons for each in a new section at
end of http://microformats.org/wiki/datetime-design-pattern
Aug 18 16:25:22 <Tantek> ?
Aug 18 16:25:58 <KragenSitaker> rfc 3339 is 4000 words, excluding the last two pages of boilerplate.
Aug 18 16:26:31 <KragenSitaker> so it's actually longer than the datetime-relevant parts of XSD but it
seems much more rigorous and clear
Aug 18 16:28:37 <DanC> my advice is: normatively cite both, and claim they specify the same
syntax, and let anybody who discovers otherwise send you a bug report
with a test case
Aug 18 16:29:12 <KragenSitaker> danc: nice hack
</pre>

The RFC3339 has a mandatory TIME portion of the DATE-TIME. Some vCard/iCalendar DATE-TIME stamps can omit the TIME. For instance, DTSTART, if that is a full day event, then you can omit the time. BDAY in vCard can be respresented by only a DATE. I like the idea of restricting the possible date formats, but i think that TIME should be optional, which it isn't in RFC3339. - [http://suda.co.uk/ brian suda]

RFC 3339 allows lowercase 't' and 'z' while XSD doesn't. Specifying RFC 3339 plus 'T' and 'Z' MUST be caps will make them the same. - [http://bitworking.org Joe Gregorio]

---

A few questions: asked by [[User:CharlesBelov|CharlesBelov]] 16:57, 24 Apr 2007 (PDT), answered by [[User:JamesCraig|JamesCraig]] on 15:58, 5 Jul 2007 (PDT).

# Would it make more sense for documenting the alternative codings pitting the abbr tag vs. other tags to be on this page? ''Answer: That documentation should go on the [[assistive-technology-abbr-results]] page.''
# Would using the title attribute of the abbr tag to encode the machine-readable date in fact cause a failure of WCAG 2.0 Accessibility? What about USA Section 508? It does appear to violate Technique for WCAG 2.0 [http://www.w3.org/TR/WCAG20-TECHS/#H28 H28: Providing definitions for abbreviations by using the abbr and acronym elements], although that is a supporting document and does not have the force of a guideline. ''Answer: Yes, it appears that is in violation of WCAG, 508, et al, so alternatives are being discussed on the [[assistive-technology-abbr-results]] page.''
# In order to maintain accessibility, would it make sense to enclose the machine-readable date in a span with a style of "display:none" instead of using the abbr tag? ''Answer: please refer to and add any suggestions to [[assistive-technology-abbr-results]].''
# For that matter, wouldn't you want to style such an abbr tag with text-decoration:none to hide that an abbr tag was used? Otherwise, visitors might cursor over the time, see the machine time, and be annoyed that their time was wasted or else be confused. And I don't think you can suppress the title from coming up if the human-readable time was inadvertently hovered. ''Answer: Microformats should not rely on CSS in order to work properly, but again, that discussion can be found here: [[assistive-technology-abbr-results]].''

== Code ==
The following regular expression (parsed VERBOSE) should break apart a datetime and cover many lightly broken cases seen in the wild. This has been tested under Python.

<pre><nowiki>
^
(?P<year>\d\d\d\d)
([-])?(?P<month>\d\d)
([-])?(?P<day>\d\d)
(
(T|\s+)
(?P<hour>\d\d)
(
([:])?(?P<minute>\d\d)
(
([:])?(?P<second>\d\d)
(
([.])?(?P<fraction>\d+)
)?
)?
)?
)?
(
(?P<tzzulu>Z)
|
(?P<tzoffset>[-+])
(?P<tzhour>\d\d)
([:])?(?P<tzminute>\d\d)
)?
$
</nowiki></pre>

== Other Proposals ==

=== strtime instructions as class names ===

Proposal by DavidLaban (alsuren on freenode) on 8 Jun 2008
It might be possible to have a slightly more readable/extensible/elegant format:
<pre><nowiki>
 16 March 1987 
</nowiki></pre>
Notes:
# Underscores are used to replace whitespace, because otherwise the the formatting string will be split into an unordered set of class attributes by many parsers (thanks go to bogdanlazarsb and gsnedders on irc for explaining this to me).
# Some subset of the placeholders should be chosen from those which are supported by both python http://docs.python.org/lib/module-time.html and php http://uk3.php.net/manual/en/function.strftime.php
# A name for the class should be decided upon. strtime might not be the best name.
# Measures should be taken to avoid the format string accidentally conflicting with other valid classes (In the above example, I have prefixed it with the string "format:")
# It might be sensible (when parsing) to strip excess whitespace from the format string and contents. This is not done in this example.
# Example python code follows.

<pre><nowiki>
date = (1987,03,16,0,0,0,0,0,0)
format = " %d %B %Y "
# To encode:
classes = ["strtime"]
encoded_format = "format:" + format.replace(' ', '_')
classes.append(encoded_format)
content = time.strftime(format, birthday)
# ... dump classes and content into your document however you want

# To decode (assuming that you have managed to extract class and format from the document already):
if "strtime" in classes:
possible_formats = [ item for item in classes if item.startswith('format:') ]
assert len(possible_formats) == 1
format = possible_formats[0].strip('format:').replace('_', ' ')
date = time.strptime(content, format)
</nowiki></pre>

==== problems with strtime proposal ====

# Possible abuse of the class attribute. microformats limit the use of the class attribute to marking up additional semantics about the data, not for (potentially) arbitrary processing/programming instructions
#* HTML 4.01 Recommendation [http://www.w3.org/TR/REC-html40/struct/global.html#adef-class defines] the <code>class</code> attribute as being "for general purpose processing by user agents". [[User:TobyInk|TobyInk]] 13:21, 8 Jun 2008 (PDT)
# Requires authors to think like programmers. The larger problem is that the proposal asks web authors to think like programmers, which severely limits the number of web authors which will be able to use the technique, since the vast majority of web authors are ''not'' programmers and have never heard of "strtime", whereas most authors (even people) on the web have seen dates like 2005-06-20 and easily understand what they mean.

In general, any publishing method that requires the author to think like a programmer is a non-starter. It is a much more of a barrier than simply using ISO8601/RFC3339, and that barrier is a far worse tradeoff than the duplication / DRY violation compromise.
[[User:Tantek|Tantek]] 09:52, 8 Jun 2008 (PDT)

* Another problem: if %A/%a/%B/%b are allowed, this raises potential problems with internationalisation. Will parsers be required to understand the names and abbreviations for days and months in potentially hundreds of different languages? [[User:TobyInk|TobyInk]] 14:09, 8 Jun 2008 (PDT)

=== Machine-data in class===
The BBC ([http://microformats.org/discuss/mail/microformats-dev/2008-June/000552.html uf-dev archive, 20/06/08, "Using class for non-human data"]) has proposed as an alternative to the empty span and title solution to use the class name in the following way:
<pre><nowiki>
10 o'clock on the 10th
</nowiki></pre>
Pros:
* Allows data to be represented in a "non-harmful" way. Will not be read aloud by screenreaders or seen as tooltips.
* Minimises mark-up used.
* Arguably more semantic than use of "title" attribute for non-human data.

Cons:
* data in the class attribute has already been discussed numerous times in the mailing list over the years and rejected and documented as an [[anti-pattern]] - captured [http://microformats.org/wiki?title=anti-patterns&diff=24271&oldid=24270 on the wiki this past January 2008].
* Possible misuse of class attribute, although as noted previously, the HTML spec states "for general purpose processing by user agents".
* The class attribute has been adopted by the broader web design community to "subclass" element semantics, and to layer additional semantics. To date, microformats has followed this existing practice developed by modern web designers ("paving the cow-paths"). This use of class for data is outside all current practices.

Discussion:
* This proposal smells icky, but I can't quite put my finger on why. Considered objectively, it does seem to be the least harmful solution proposed so far. [[User:TobyInk|TobyInk]] 06:06, 21 Jun 2008 (PDT)
* I really like it, especially given the HTML4 spec gives this as an IMO perfectly valid use (on both id and class, with the following examples given in the id section: "identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc."). Clean and simple. [[User:Dracos|Dracos]] 03:53, 23 Jun 2008 (PDT)
* I suggest dropping the redundant 'data-' prefix, unless someone can suggest a feasible case with two time-stamps requiring different prefixes. The proposal then becomes [http://www.robertnyman.com/2008/04/28/do-we-really-need-microformats/#comment-263408 one I've made before] [[User:AshSearle|AshSearle]]
** Valid class names cannot begin with a number, so a date needs some sort of letter prefix. It's sensible to make this prefix meaningful and reusable in some way. [[User:Phae|Phae]]
*** They can't in CSS, but they can in (X)HTML. http://examples.tobyinkster.co.uk/numeric-classes.html [[User:TobyInk|TobyInk]] 06:53, 24 Jun 2008 (PDT)
**** Creating classes in HTML that can't be referenced in CSS is a bad thing. Using colons and starting with numbers fall into that category. http://www.w3.org/TR/CSS21/syndata.html#characters Also, replacing whitespace with underscores breaks the ISO compatibility, which sorta defeats the whole point of using existing standards. Finally the class names are unordered, so trying to use them in a series is a bad idea. --[[User:Atamido|Atamido]] 11:43, 30 Jul 2008 (PDT)
***** They can be referenced in CSS, just not using the "dot notation". They can be referenced using attribute selectors, which are supported in all modern browsers (but not IE6). [[User:TobyInk|TobyInk]] 13:21, 30 Jul 2008 (PDT)
****** They could also be referenced by escaping the characters, but that still excludes >99% of current use cases. I'd wager that most authors don't even know about the limitations and would run into issues in implementation. --[[User:Atamido|Atamido]] 13:47, 30 Jul 2008 (PDT)
***** I don't think the proposal relies on classes being in any particular order. Even if it did, I don't know of any DOM implementations which do not provide the contents of the class attribute in their original order. [[User:TobyInk|TobyInk]] 13:21, 30 Jul 2008 (PDT)
** Not to advocate too strongly for designing for parsers (generally a bad idea), *but* having a 'data-' prefix on a class name would make identifying data orders of magnitude easier for parsing. Otherwise, how do we know what's data and what's just another class name for some other purpose? [[User:DrewMcLellan|Drew]]
** A 'data-' prefix would help authors tasked with maintaining or reviewing a page to understand the purpose of a class name that may have been applied by another author. The data prefix communicates very simply that the class name is precisely that, data. Therefore the value is less likely to be accidentally removed or changed, making for a more robust design. [[User:DrewMcLellan|Drew]]
*** I concede - regardless of whether it's valid (X)HTML / CSS - a prefix is needed to distinguish data values from genuine content. ISO 8601 allows date-time to be as simple as "2004", which could easily be misinterpreted. e.g. if a CMS outputs product model numbers into the class attribute for some other purpose. --[[User:AshSearle|AshSearle]] 01:42, 25 Jun 2008 (PDT)
*** Using <code>data-</code> as the prefix here is undesirable, as it now conflicts with HTML5's proposed <code>-data</code> prefix on attributes. It's undesirable to set ourselves up for future confusion with our own conflicting specification of ‘a data prefix’. A different prefix should be considered. See: [http://www.w3.org/html/wg/html5/#custom HTML5 Editors Draft: Embedding Custom Non-Visible Data] —[[User:BenWard|BenWard]] 07:34, 16 Jul 2008 (PDT)
* -1 [[User:Tantek|Tantek]]. I'm vehemently opposed to putting data in the class attribute. We ''must'' find better alternatives. We must not go down the path of invisible (dark) (meta)data - IMHO that [[principle]] is inviolable for microformats.
** [[User:JakeArchibald|JakeArchibald]] If you're so opposed, it'd be useful to see some justification.
*** See above cons. Already discussed/rejected many times in the history of microformats discussions. In short, quit wasting time on old ground. Abuses class attribute, or if you prefer, introduces a *new* use of the class attribute, unlike microformats to-date which have simply made use of a well established semantic of the class attribute. And worst of all, completely violates the visible data [[principle]]. Rejectable on that alone.
**** The fact that something has been discussed and rejected before is not sufficient grounds for dismissing it out of hand once additional research and thinking has taken place. The <abbr> datetime pattern arguably abused the title attribute and introduced a new use of the title attribute. In the example given (<code><nowiki>10 o'clock on the 10th</nowiki></code>), the data is presented as "10 o'clock on the 10th" - very visible. Yes, of course, it's possible to abuse this proposed pattern, and hide the data, but the same can be said of the abbr pattern or even the class pattern given CSS's display:none property. Experience shows that in most cases, people ''won't'' abuse the pattern to hide data, as they actually ''want'' to show the data on their pages. [[User:TobyInk|TobyInk]] 13:52, 24 Jun 2008 (PDT)
**** It's not an abuse of the class attribute according to the HTML spec. as I read it. Whereas using title for non-human data is (the spec says audio agents may read it aloud, for example). If it's a new use, it's one the writers of HTML4 considered, so it wasn't new to them. [[User:Dracos|Dracos]] 03:38, 25 Jun 2008 (PDT)
** Relevant princeples are 'humans first, machines second', and 'visible data is ''better'''. These are ''preferences'', not inviolable principles. Besides, the existing datetime spec doesn't adhere to these principles anyway: prioritising humans first, <code><nowiki>let's discuss this at the next meeting</nowiki></code> should be marked up as <code><nowiki>let's discuss this at the <abbr title="28th June 2008 at 3:15pm">next meeting</nowiki></code>. There's a conflict between human- and machine-readable dates. It makes more sense to 'hide' the machine-readable data in the only attribute available to us: <code>class</code>. --[[User:AshSearle|AshSearle]] 03:02, 25 Jun 2008 (PDT)
*** Indeed - by their nature, ''principles'' are ''generalisations'', and while broadly useful, usually have exceptions. After experience, the microformats community is beginning to see some of these. Human vs machine dates is the one gathering the most interest at the moment, largely thanks to <abbr class="help" style="border-bottom:1px dotted" title="the Web Standards Project">WaSP</abbr> and auntie, but I think other properties which will probably emerge as exceptions to the general microformats principles are hReview's <code>type</code> property, and the its namesake subproperty for hCard's <code>tel</code>, <code>email</code> and <code>adr</code> (and <code>label</code>?) properties. [[User:TobyInk|TobyInk]] 12:51, 25 Jun 2008 (PDT)

==== Experimental Parser Support ====

[http://buzzword.org.uk/cognition/ Cognition 0.1 alpha 10] will include experimental support for this pattern, and the [http://srv.buzzword.org.uk Cognition web service] already does. Notes:
* Support is ''opt-in''. Publishers must explicitly request support for the pattern, by including a [[profile-uris|profile URI]] of <code><nowiki>http://purl.org/uF/pattern-data-class/1</nowiki></code> in their document head.
* Support is not limited to date-time properties, but any microformat properties.
* data-X classes must use percent-encoding to encode spaces and other characters not allowed in class names.
* The data-X class must be found on the same element as the microformat property class. That is, you cannot use: <pre><nowiki>10 o'clock</nowiki></pre>
<ul><li>Multiple data-X classes may occur on the same element. When these are found, the longest string is used. This allows for: <pre><nowiki>The 10th</nowiki></pre> which may be useful for styling or other non-microformat purposes.</li>
<li>Can be combined with value excerpting. e.g. <pre><nowiki>

The concert will be held on
the 4th of August
starting at
7:30pm precisely.

</nowiki></pre></li></ul>

=== date and time separation using value excerption ===

==== summary ====
By specifying a more precise parsing of the use of "value" excerption inside all datetime properties (e.g. dtstart, dtend, published, updated etc.), dates and times can be marked up separately, thus reducing/minimizing (and potentially eliminating) the readability issues that come with compound ISO8601 datetimes.

==== introductory example ====
The sentence:

<pre><nowiki>
The weekly dinner is tonight at 6:30pm.
</nowiki></pre>

would be marked up as:

<pre><nowiki>
The weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
at <abbr class="value" title="18:30">6:30pm</abbr>.
</nowiki></pre>

==== advantages ====
* re-uses the readable [[abbr-date-pattern]]
* identifies a similarly readable abbr-time-pattern.
* minimizes DRY violation distance, keeps machine data on exactly the same element as the respective human data
** even better than [[abbr-datetime-pattern]] does, which, in practice from experience often required specifying the date in machine readable form on the human readable time (separate from the human readable date).
* introduces no new class names - [[principle]] of minimal invention
* introduces no new use of the class attribute - principle of minimal invention again
* introduces no new syntax ([[datetime-design-pattern#problems_with_strtime_proposal|see above]] about any publishing method that requires the author to think like a programmer being a non-starter, and introducing new syntax almost always requires authors to think like programmers).
* and most importantly, introduces no dark data.

==== issues ====
Some potential issues were raised in IRC, and it helps to document/resolve them so that they are not brought up repeatedly.
* [[http://rbach.priv.at/Microformats/IRC/2008-06-24#T163114 Does this sufficiently address the concerns raised with the current use of abbr-pattern?]]
*# The [[abbr-date-pattern]], as documented and explained by [[User:Adactio|Jeremy Keith]] is just fine (in contrast to the [[abbr-datetime-pattern]]).
*# Similar to the [[abbr-date-pattern]], this proposal implies/introduces the abbr-time-pattern, which is similarly acceptable.
*# In addition, as long there is incremental improvement, we are making progress. It is more important to take small steps that we know will help some things, rather than try to take a big step that is more risky in the attempt to help more but may not actually do so (as most big changes don't), therefore "sufficiently" is a flawed way of evaluating incremental fixes.
* Exposes data through tooltips. Separating into 2008-06-07 and 18:03 improves the ability for humans to consume the data, but still exposes data through tooltips and speech in formats that the publisher did not choose to use. --[[User:BenWard|BenWard]] 04:52, 25 Jun 2008 (PDT)
*# This is a feature, not a bug. By making the duplicated data at least *somewhat* visible (rather than fully invisible), effective data quality is increased due to the fact that the probability of the ISO8601 and locale-specific data getting out-of-sync is reduced because of the increased visibility (and therefore the increased inspectability and more eye-balls looking at/for problems effect).
*# Workaround: if a site publisher wishes to customize the presentation of tooltips, they can do so with a nested span with title.
*#* That proposes extraneous mark-up maintain some publisher's wish not to have a tool-tip in the first place. I object to a microformat pattern requiring an immediate work-around to meet publisher's desires. It goes against ‘Humans first…’. --[[User:BenWard|BenWard]] 09:09, 30 Jun 2008 (PDT)
*#*# Additional markup has nothing to do with "Humans first".
*#*# Additional markup to work-around minor issues (e.g. CSS, cross-browser compatibility, etc.) is a well accepted modern web design practice. It's not ideal, but it is both accepted and widely practiced. With the use of <code></code> and <code><div></code> elements, it's also semantically neutral, therefore not a problem from that perspective either.
*#*# Finally, it should not be our goal to try to satisfy *every* publisher, for that would make every microformat beholden to every publisher and contort the design of microformats in really poor ways. We must accept that not all publishers will adopt all microformats and that is ok. Our goal to incrementally increase the number of publishers that adopt microformats, not to try to satisfy each and every one.
* Semantic misuses of ABBR. That ‘tonight’ is ever a textual, human abbreviation of ‘2008-06-24’ is not accepted.
*# Semantic stretch not misuse. It is a semantic abbreviation rather than a purely syntactical (character shortening) abbreviation, but it is an abbreviation in context nonetheless. Though this may stretch what may be commonly expected as an "abbreviation", the HTML4 spec does seem to allow some flexibility here ([http://www.w3.org/TR/html401/struct/text.html#h-9.2.1 HTML 4.01 9.2.1 Phrase elements]).
* Maintaining proper sentences with the expanded form. It is not always possible to use this mark-up and maintain proper sentences with the expanded form. e.g. <code>it's my <abbr class="bday" title="2005-06-20">birthday today</abbr>!</code> becomes ‘it's my 2005-06-20!’. And thus audio rendition of such titles can be nonsensical - "The weekly dinner is two thousand and eight dash zero six dash twenty four at eighteen thirty."
*# This can and should be addressed by improving authoring examples so that practices improve with experience.
* Publishing practices and desires show us that authors are not willing to compromise the semantics of abbr. [[User:Phae|Phae]] 04:30, 27 Jun 2008 (PDT)
*# Without specific citations of which authors and what specific issues they have, we are unable to address their issues.
*# See also above - not our goal to satisfy *every* publisher, but rather to incrementally satisfy more and more. We must accept that there may be some authors we are unable to satisfy in the immediate/short-term.
* [[http://rbach.priv.at/Microformats/IRC/2008-06-24#T163435 That's getting pretty complicated]]
** Much less complicated than inventing yet another syntax ( " { ... } " ???? ) that web authors would have to learn.
*** But it's all in one place, rather than spreading it out.
**** The spreading it out is what current content publishing practices do already! It is much more important to map the machine data as close to the existing publishing practice as possible, than to try to "put it all in one place". The "put it all in one place" way of thinking is why people ended up sticking so much invisible metadata in the head of the document, which we know fails.

==== content requirements ====
Some requirements which enhance both human readability, ''and'' machine parsability (best of both) :
* date value excerpts MUST use hyphen separators. E.g. 2008-06-24. Not ok:20080624.
* time value excerpts MUST use colon separators (seconds optional, implied :00 if absent). E.g. 18:30 or 18:30:00. Not ok:183000.
* timezone value excerpts MUST use leading plus or minus and NO colon separator. E.g. -0700. Not ok:-07:00.

==== derivation ====
It's important to document the derivation/background of a brainstorm/proposal as it allows others to see some of the thinking that went into it, and avoid having to rediscuss alternatives already considered, and helps provide understanding as to why aspects of the design are as they are.
===== example with datetime =====
Here is a short code example:
<pre><nowiki>
the weekly dinner is tonight at 2008-06-24T18:30
</nowiki></pre>
===== example with abbr datetime =====
However that's not the easiest to read, nor do most people publish that as human visible text, so per the abbr-datetime pattern:
<pre><nowiki>
the weekly dinner is tonight at <abbr class="dtstart" title="2008-06-24T18:30">6:30pm</abbr>
</nowiki></pre>

which has raised two issues:
# When "2008-06-24T18:30" is inspected by a human reading a tooltip, or spoken by a screen reader, it's not the most understandable thing (precise citation needed, perhaps an mp3 with screen reader used version info).
# There is a non-local violation of DRY (which IMHO is a worse problem, as it leads to worse data quality -[[User:Tantek|Tantek]]). That is, the "date" information is now not only in the text twice (as it was before), but those two instances of the date information are not on the same element, which makes it worse. That is, "tonight" is in the prose, ''outside'' of the element with the precise date "2008-06-24".

In analysis of examples of event information on the web, the date and time are often published in separate elements, often for display purposes.

Thus it is this existing content publishing practice which leads to this brainstorm proposal, to essentially to introduce a date and time value excerption longhand.

(Initially [http://rbach.priv.at/Microformats/IRC/2008-06-21#T181634 Tantek's idea that he bounced off Jeremy Keith] ([http://rbach.priv.at/Microformats/IRC/2008-06-24#T124652 similar idea conceived by Drew independently]) was to [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161819 introduce new classes "datevalue", "timevalue"] and "tzvalue" for this purpose, but [http://rbach.priv.at/Microformats/IRC/2008-06-24#T171603 Bob Jonkman pointed out] that HTML5's time parsing algorithm enables a single <nowiki><time></nowiki> element to contain dates or times (with or without timezone) without having to explicitly say whether the value contains dates or times (with or without timezone). [http://rbach.priv.at/Microformats/IRC/2008-06-24#T171723 Bob then proposed] that thus all was needed was a single new "datetime" class name. This was the key realization that allowed minimal invention. Tantek pointed out that since from the type of property we already know it is a datetime, [http://rbach.priv.at/Microformats/IRC/2008-06-24#T171835 there was no need for even one new class name], that we could simply re-use "value" excerption, and simply more precisely specify the semantics/parsing in the case of datetime properties.)

===== example with new date and time value excerpts =====
Thus we markup the date and time separately, as value excerpts, using the [[abbr-date-pattern]] and an implied parallel abbr-time-pattern:

<pre><nowiki>
The weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
at <abbr class="value" title="18:30">6:30pm</abbr>.
</nowiki></pre>

===== separate subtrees =====
The proposal also allows setting the date and time in separate element subtrees as well, which may be necessary for some document structures:

<pre><nowiki>
the weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
at <abbr class="value" title="18:30">6:30pm</abbr>.
</nowiki></pre>

Note the two instances of dtstart, one of which sets the date for the dtstart, and the other of which sets the time.

The idea being, when a parser sees a datetime property (e.g. dtstart) with a value excerpt, that it only "set" the component of its full value that is specified by the value excerpt (e.g. the date), and that if lacking a complete datetime, it continue to parse additional instances of that datetime property for the remaining component(s) (e.g. the time).

Of course this only works for singular properties, but fortunately all instances of datetime properties so far are singular, so this works.
* hCard's <code>rev</code> is plural. [[User:TobyInk|TobyInk]]
** can someone give a reference to this being the case? The RFC says "The value distinguishes the current revision of the information in this vCard for other renditions of the information." Does it make sense to have multiple REV dates in a single vCard?
*** The RFC is ambiguous as usual, but a contact card could conceivably have had several changes made to it, with a <code>rev</code> for each. ("Change logs" are fairly common on the web.) The [[hcard|hCard spec]] is fairly specific about which properties are [[hcard#Singular_vs._Plural_Properties|singular]] and which are not, and <code>rev</code> is not included in the list of singular properties.

===== reusing date data for multiple datetime properties =====
This also provides a *very* convenient way to re-use the same date information for start and end, e.g. expanding the example:

<pre><nowiki>
the weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
from <abbr class="value" title="18:30">6:30</abbr> -
<abbr class="value" title="20:30">8:30pm</abbr>.
</nowiki></pre>

Note what just happened. we just eliminated another duplication of date information by reusing the start *date* information for the end *date* information and *only* specifying the end *time* information separately for the two properties.

Reducing the duplication (or triplication) of such data helps to reduce the chances of (even inadvertent) data corruption/drift/divergence among any duplicates.

===== time zones =====
There are a few choices for timezones.
# Simply include the time zone information as part of the time "value". E.g. <code><nowiki><abbr class="value" title="18:30-0700">6:30pm</abbr></nowiki></code>
# Or use another value excerpt for the timezone (was: <del>introduce the class name "tzvalue"</del>) E.g. <code><nowiki><abbr class="value" title="18:30">6:30pm</abbr> <abbr class="value" title="-0700">PDT</abbr></nowiki></code>
# Or allow both and let web authors decide. This is the current leaning.
#* if web authors want to specify timezone as part of the time (first example above), they can,
#* or if web authors visibly publish the timezone separately (second example above), then they can mark that up.
#* or if web authors wish to omit timezone information, they can do so as well, as most do today. In practice this works fine, as it creates a "floating" time which works fine in far more than the 80/20.

(more to come, documenting [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161740 from IRC logs])

==== discussion ====
Opening up a discussion section even though documentation [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161740 from IRC logs] is still in progress. :)

* regarding the [[datetime-design-pattern#advantages|advantage]] of "and most importantly, introduces no dark data."
** "Dark data" is sometimes what publishers *want* to publish. To use the example of TV schedules which kick started the renewed discussion in this area, publishers will often not want to display the date. For instance, if a page entitled "Tomorrow's TV" and containing 300 different programmes marked up with <code>dtstart</code>, it is superfluous to explicitly display the date for each one. With this proposed solution the [[include|include pattern]] could be used to include the date into each vevent, but a visible link to the date on each programme would simply be confusing. Sometimes it just makes sense to hide some of the information you're publishing as a microformat - because the information you want to make explicit to parsers can be inferred from context by humans, or is more appropriately displayed at a different level of granularity for machines and humans. [[User:TobyInk|TobyInk]] 14:26, 24 Jun 2008 (PDT)
*** It doesn't matter whether publishers *want* to publish dark data or not. Invisible data always leads to poorer quality data. Publishers publish all kinds of invisible metadata in the heads of documents etc. because they want to, but their desire doesn't stop the data from becoming obsolete, diverging from the actual visible data etc. The quality of the data matters more than any publishers wish(es) of publishing in a specific format, or in a hidden way. In the example you gave, using the include pattern in that way would not result in any visible links, but merely empty include anchors. It never makes any sense to actually hide "some of the information you're publishing as a microformat", because historically that always results in some loss of data quality over time and thus the microformats [[principle]] of visible data instead of invisible metadata. [[User:Tantek|Tantek]] 14:32, 24 Jun 2008 (PDT)
**** All microformats hide ''some'' data. In the example <code><nowiki>01632 960123</nowiki></code>, the information that the long string of numbers represents a telephone number is invisible. And making it visible (<code><nowiki>Tel: 01632 960123</nowiki></code>) violates DRY. It's just a matter of where to draw the line.
***** That statement makes the mistake of conflating *type* data and *content* data. "tel" is not content data, just as <nowiki></nowiki> is not content data. It's markup, indicating the type of the data. Markup (type data) being invisible to the user has worked just fine. Content (content data) being invisible to the user is the problem of dark data. Or rather, if you think that everything is data, then you really should be spending time developing in a system that is built on that assumption, e.g. RDF, rather than microformats, which are built on HTML, and the clear separation of type of data (HTML elements, microformats properties) and content data (inner text, text attribute values).
****** My point is that there isn't a ''distinction'' between the two, but a ''continuum''. The choice of where to draw the line is never a clear one and always somewhat arbitrary. The vCard standard could quite easily have ended up with separate "TEL", "FAX" and "CELL" properties, in which case hCard would have ended up with <code><nowiki><foo class="tel"></nowiki></code>, <code><nowiki><bar class="fax"></nowiki></code> and <code><nowiki><baz class="cell"></nowiki></code>. Going the other way, they could have stored e-mail addresses as mailto: URLs, and then hCard would have <code><nowiki><a class="url" href="mailto:quux@example.com"></nowiki></code>. They chose the way they did, and as a result in hCard the distinction between a mailto: URI and an http: URI is largely invisible (in most circumstances only obvious by looking at the status bar when hovering), but the distinction between a telephone number and a fax number is visible. But that wasn't the only possible (nor the only reasonable) outcome.

=== HTML 5 <code><time></code> Element ===

[http://microformats.org/wiki/hcalendar-issues#html5-time-element See hCalendar issues]

=== Plain Old English alternative to ISO date ===

Example (in English):

<pre>
<abbr title="January 25th, 2008" class="dstart" lang="en-us">1/25</abbr>
</pre>

<pre>
January 25th, 2008
</pre>

If <code>lang="en-us"</code>, the format of the date used in the <code>title</code> attribute must conform to [http://www.ego4u.com/en/cram-up/vocabulary/date/written dates writing rules in American English].

Example (in French):

<pre>
<abbr title="25 Janvier 2008" class="dstart" lang="fr">25/1</abbr>
</pre>

If <code>lang="fr"</code>, the format of the date used in the <code>title</code> attribute must conform to date writing rules in French.

====Benefits====

* Human-hearable: should work nicely with screen readers (to be tested).
* Human-readable
* Compliance with semantics of abbr.
* Very easy to use by HTML human authors.
* DRY compliant if HTML human authors are willing to write in correct English

====Discussion====

* Locale-specific parsing logic.
* Not all cultures use the same calendar — Dan Brickley
* There are situations where markup clues used for localisation might be misleading, such as people using microformats in a post on a site they do not themselves run that may even be in a different country. (a shared blogging site that allows html tags in posts would be a good example here) — Michael MD
** Couldn't the person or tool adding the microformat annotation also add a lang attribute at the same time? — Benjamin Hawkes-Lewis
* Cognition already supports this as a last ditch attempt at parsing dates - but I wouldn't recommend it get adopted widely. It's too unreliable; too much work to deal with internationalisation; too much work full-stop in languages that don't provide a handy library that takes care of most of the work. — [[User:TobyInk]]
** I don't think we need to support all locales at once. I don't know in how many written languages BBC publishes in, but it might be that supporting en-uk and en-us might be enough for a start. Also, one can imagine that Microformats tools could focus on the most common written languages and then expose hooks for others to implement support for other locales. — Guillaume Lebleu
** What are our priorities? Making programmers' life easier or making content authors and content readers' life easier? — Guillaume Lebleu
*** In Australia dd/mm/yyyy is commonly used, but a significant minority of sites in Australia use US-style mm/dd/yyyy because it is the default setting in their CMS. How would a parser be able to tell which part is the day and which is the month? Getting it wrong would be worse than not getting it at all! Until the use of ambiguous formats can be ''wiped out'' we ''will'' need a version for machines! — Michael MD
*** problem which hasn't been raised with regards to this proposal is that even though you are proposing a fixed date format, because it *looks* like natural language, authors will assume that it *is* natural language, and simply start including dates in whatever format they like. Then you get an NLP "arms race" between publishers and parsers. If you don't believe that that will happen, take a look at what happened with RFC 822 dates, which are simply a mess. — [[User:TobyInk]]
**** Very true the more you make the date look like natural language, the less it looks like a fixed format. I really don't want us to get involved in any form of NLP, it just would not work. I think it was Mike who said that dates have to be parsed correctly, no level of error is acceptable. I don't want to travel to an event on the wrong day because a parser got the date wrong — Glenn Jones

====Notes====

* Could work alongside with the existing [[datetime-design-pattern]]: if ISO date parsing fails, try parsing the title as a human-readable plain old English/French/... date according to the locale.

===<code><object></code> element to represent dates===

* Re-raised by George Brocklehurst on June 25th 2008.

The idea was to do something like this:

<pre><code><object data="20050125">January 25</object></code></pre>

* From what Tantek [http://tantek.com/log/2005/01.html said on his blog] , the main reason for not using objects was that they were not well supported in Safari. However, Safari's object support is now much improved: fallbacks are supported and display:inline and intrinsic sizing will work correctly. Safari 2.0.2, which came out in November 2005, was the first version to [http://webkit.org/blog/32/webkit-fixes-in-safari-202-mac-os-x-1043/ contain these improvements]. — George Brocklehurst
* The following appears to be well behaved inline in Safari 2.04 and 3.1.1, Firefox 1, 1.5, 2 and 3, and Opera 7, 8 and 9: <code><object class="dtstart" data="data://20080712"></object></code>. Test case: http://pastie.org/224023 — Ben Ward
** IE 6, 7 and the beta version of IE 8 all visibly render the object element as a small box, similar to the way they would render a missing image: http://georgebrock.com/misc/object-in-ie.png — George Brocklehurst
** Absolute URIs can't start with a number, but relative ones can - and the data attribute is permitted to contain relative URIs. [Don't need to use data:// URI) — Toby A Inkster
* Could also look at <code><object class="dtstart"><param name="value" value="20050125" />January 25</object></code> — Scott Reynen
* 1. The purpose of the <object> element is to allow the browser to run an external application for a non-native data type (e.g., Java applet). See: http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.3. Object is not the right way to go in this case. — Sarven Capadisli

==Individual markup of each date/time component==

A combination of suggestions that originated from this [http://www.mail-archive.com/microformats-discuss@microformats.org/msg10218.html post]

This is suggested as a complementary alternative to datetime-design-pattern, when the use of the pattern is not possible due to accessibility reasons.

suggested class names:
* <code>date</code>
* <code>time</code>
* or maybe <code>datetime</code> ?
* <code>s</code> for seconds
* <code>min</code> for minutes
* <code>hr</code> for hours
* <code>ampm</code> for AM/PM
* <code>tz</code> for timezone. (ex. <code>GMT</code>)
* <code>tzo</code> for timezone offset (ex. <code>-7</code>)
* <code>day</code>
* <code>mo</code> for months
* <code>yr</code> for year

For a complete datetime:

<pre>
October 5, 2004 at 6PM
</pre>

<code>date</code> maybe not required since <code>dstart</code> IS a <code>date</code>.

For a duration:

<pre>

1:
3:
42

</pre>

'''Issues'''
* the internationalization issue is not addressed, but it is limited to the month of the year.

== See Also ==

* [[Main_Page#Design_Patterns|All microformat design patterns]]
* [[abbr-design-pattern]] is used by [[datetime-design-pattern]]
* [[date-design-pattern]] is a subset of [[datetime-design-pattern]]
* HTML 4.01 definition of <code><[http://www.w3.org/TR/REC-html40/struct/text.html#edef-ABBR abbr]></code> element
* RFC [http://www.faqs.org/rfcs/rfc3339.html 3339]: Date and Time on the Internet: Timestamps
* W3C: [http://www.w3.org/TR/NOTE-datetime Note on Datetimes]
* Markus Kuhn: [http://www.cl.cam.ac.uk/~mgk25/iso-time.html A summary of the international standard date and time notation]
* Wikipedia: [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]

datetime-design-pattern

2008-07-01T16:38:01Z

Guillaume Lebleu: corrected typo

<h1> Datetime Design Pattern </h1>
This is a page for exploring a datetime design pattern.

{{TOC-right}}

== Purpose ==
* Use the [[datetime-design-pattern]] to make datetimes that are human readable also formally machine readable.

== Practical Need ==
* This design pattern arose as a result of solving the practical need for human readable dates for [[hcalendar|hCalendar]].

== How to use it ==
* enclose the human-friendly datetime that you want to make machine readable with <code><abbr></code>
* as per the [[class-design-pattern]], add the appropriate <code>class</code> attribute to the <code>abbr</code> element
* add a <code>title</code> attribute to the <code>abbr</code> element with the machine readable [[iso-8601|ISO8601]] datetime or date as the value

==Current uses==

The pattern, which is now available as part of [[hAtom]], [[hcalendar|hCalendar]], [[hcard|hCard]] and [[hreview|hReview]], is:

:<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">Date Time</abbr></pre>

where foo is the semantic classname which is being applied to this date/time, the title of the <abbr> is an ISO 8601 date/time, with an appropriate level of specificity, and "Date Time" is a human-friendly representation of the same date/time.

An alternative, if you are using UTC-based timestamps, would be:

:<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SSZ">Date Time</abbr></pre>

with a single "Z" as per [[iso-8601|ISO 8601]]

Ruby: An easy way to get this format from a DateTime is this:
:<pre>DateTime.now.to_s</pre>

== Profile of ISO8601 ==

Any [[microformat]] using the date-time-design pattern {{should}} use a profile of [[iso-8601|ISO8601]]. There are currently two widely used profiles which {{should}} be reused.

* RFC 3339
* [http://www.w3.org/TR/NOTE-datetime W3C Note on Datetimes]

==Accessibility issues==

Note: Some accessibility issues have been raised([http://www.webstandards.org/2007/04/27/haccessibility/]) with Datetime Design Pattern, and concerns that its use could breach WCAG accessibility guidelines, that are being addressed as part of the [[abbr-design-pattern-issues]] discussion. Possible change recommendations may follow after the accessibility testing is complete. The accessibility concerns are considerably lessened, even eliminated when using the [[date-design-pattern]], a subset of the [[datetime-design-pattern]].

== Discussion ==
This pattern is likely to be highly resuable.

--[[User:RyanKing]]

Can this not be viewed as a microformat in itself?

--[[User:DimitriGlazkov]]

It could, but inventing a microformat for the sake of inventing a microformat is against the microformat principles.
If there is a specific real world problem (and uses cases) that such an elemental microformat would solve, then it would be worth considering.

Until then it is best to keep the <abbr> datetime concept merely as a microformat design pattern, to be used in _actual_ microformats that have a demonstrated practical need.

-- [http://tantek.com/log/ Tantek]

Excerpt from #microformats Aug 18th. Please edit!

<pre>
Aug 18 15:16:14 <Tantek> DanC, what do you think of RFC3339?
Aug 18 15:17:14 <Tantek> ISO8601 subset
Aug 18 15:17:19 <DanC> Date and Time on the Internet: Timestamps http://www.ietf.org/rfc/rfc3339.txt
Aug 18 15:17:30 <DanC> Klyne is a good guy. I wonder if I talked with him about this.
Aug 18 15:17:32 <Tantek> compat with W3C-NOTE-DATETIME
Aug 18 15:17:50 <Tantek> compat with xsd:dateTime
Aug 18 15:17:57 <Tantek> it's a strict intersection subset
Aug 18 15:17:59 <DanC> I consider W3C-NOTE-DATETIME obsoleted by XML Schema datatype-- yeah.. xsd:dateTime
Aug 18 15:18:32 <Tantek> compare/contrast normatively using xsd:dateTime vs. RFC3339
Aug 18 15:18:41 <Tantek> note: Atom 1.0 chose RFC3339
Aug 18 15:18:50 <Tantek> i would like input from the microformats community on this
Aug 18 15:19:27 <DanC> in what context are you evaluating RFC 3339?
Aug 18 15:19:28 <jcgregorio> http://bitworking.org/news/Date_Constructs_in_the_Atom_Syndication_Format
Aug 18 15:21:24 <DanC> which microformat is the question coming from, Tantek ?
Aug 18 15:23:31 <DanC> " The grammar element time-second may have the value "60" at the end of
Aug 18 15:23:31 <DanC> months in which a leap second occurs" The XML Schema WG is in the 27th level of
leap-second-hell for the past few months, I gather.
Aug 18 15:24:21 <DanC> yeah... here's the scary bit: " Leap seconds cannot be predicted far into the
future. The
Aug 18 15:24:21 <DanC> International Earth Rotation Service publishes bulletins [IERS] that
Aug 18 15:24:21 <DanC> announce leap seconds with a few weeks' warning."
Aug 18 15:26:03 <Tantek> DanC, which microformats? any/all that use datetime fields.
Aug 18 15:26:36 <DanC> hard to give useful advice, then.
Aug 18 15:26:58 <DanC> I expect they'll use datetime fields for different things that have different
cost/benefit trade-offs
Aug 18 15:27:26 <DanC> do you know of any particular differences that matter to anybody?
Aug 18 15:56:43 <KragenSitaker> RFC3339 suggests -07:00, which seems like an improvement over -0700 anyway
Aug 18 15:56:49 <Tantek> Kragen, agreed
Aug 18 15:57:01 <Tantek> RFC3339 is certainly preferable to the ISO8601 subset in iCalendar
Aug 18 16:05:57 <DanC> Tantek's right, Kragen; iCalendar looks like it solves the local timezone
problem but doesn't.
Aug 18 16:06:14 <DanC> and it's true that there's no standard solution to the local timezone problem
Aug 18 16:06:39 <Tantek> so instead of appearing to solve the problem but not solving it, we chose to
provide the ability to *approximate* the local timezone using e.g. "-07:00"
Aug 18 16:06:49 <DanC> the simplest thing is to have people use Z time in hCalendar. But I gather
that's unacceptably unusable?
Aug 18 16:07:35 <Tantek> DanC, yes, the simplest thing is to have everyone use UTC Z
Aug 18 16:07:38 <Tantek> However
Aug 18 16:07:50 <Tantek> it is not *nearly* as usuable/verifiable
Aug 18 16:07:55 <Tantek> as -07:00 etc.
Aug 18 16:08:02 <Tantek> hence the decision to go with the latter
Aug 18 16:08:12 <Tantek> some degree of human verifiability is important here
Aug 18 16:14:21 <Tantek> DanC, my perception is that RFC3339 is a subset
Aug 18 16:17:00 <DanC> time-numoffset = ("+" / "-") time-hour ":" time-minute
Aug 18 16:17:34 <DanC> ok, then I can't see any differences. (modulo recent leap seconds issues that
may affect xsd:dateTime )
Aug 18 16:18:07 <Tantek> would be interesting to know why Atom 1.0 chose RFC3339 over xsd:dateTime
Aug 18 16:18:21 <Tantek> if there was a "real" reason or if it was arbitrary / coin-flip.
</pre>

Here's an exhaustive [http://www.imc.org/atom-syntax/mail-archive/msg13103.html comparison] from ndw. I think xsd:dateTime also allows unqualified local times, while RFC3339 allows only UTC with no known timezone (-00:00). In the end, Atompub followed the advice of [http://www.imc.org/atom-syntax/mail-archive/msg13244.html Sam Ruby] and [http://www.imc.org/atom-syntax/mail-archive/msg13248.html Scott Hollenbeck], our area director. Atom dates make some additional restrictions on RFC3339, such as uppercase T and Z characters for compatibility with xsd:dateTime, RFC3339, W3C-DTF, and ISO8601. --[http://franklinmint.fm Robert Sayre]

<pre>
Aug 18 16:18:43 <KragenSitaker> rfc3339 is pretty short.
Aug 18 16:19:36 <Tantek> DanC, BTW, which came first? REC for xsd:dateTime or RFC3339?
Aug 18 16:19:50 <DanC> RFC3339 is dated July 2002 ...
Aug 18 16:19:54 <KragenSitaker> Right --- and you might be able to understand xsd:dateTime without
reading all of xml schema, you wouldn't be confident of it
Aug 18 16:20:25 <DanC> W3C Recommendation 28 October 2004 ... but that's 2nd ed...
Aug 18 16:20:47 <DanC> W3C Recommendation 02 May 2001
Aug 18 16:22:10 <DanC> I don't see a BNF in http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime ...
Aug 18 16:22:43 <KragenSitaker> yeah, appendix D of the current xml schema datatypes document seems
a little scanty, actually
Aug 18 16:23:28 <DanC> ah... 2nd ed of http://www.w3.org/TR/xmlschema-2/#date is much more
explicit about syntax.
Aug 18 16:23:30 <KragenSitaker> it's 1100 words but still doesn't give any examples
Aug 18 16:23:35 <DanC> still, it's given in prose and not BNF
Aug 18 16:24:17 <KragenSitaker> sections 3.2.9 through 3.2.14 seem to be the relevant ones around #date
Aug 18 16:24:29 <KragenSitaker> which is another 2200 words
Aug 18 16:24:42 <DanC> wow... they changed the canonical form of date from always-Z to
timezone-allowed between 1st edition and 2nd edition
Aug 18 16:25:01 <Tantek> Kragen, DanC, these are very good analyses
Aug 18 16:25:21 <Tantek> could I ask you to summarize the pros/cons for each in a new section at
end of http://microformats.org/wiki/datetime-design-pattern
Aug 18 16:25:22 <Tantek> ?
Aug 18 16:25:58 <KragenSitaker> rfc 3339 is 4000 words, excluding the last two pages of boilerplate.
Aug 18 16:26:31 <KragenSitaker> so it's actually longer than the datetime-relevant parts of XSD but it
seems much more rigorous and clear
Aug 18 16:28:37 <DanC> my advice is: normatively cite both, and claim they specify the same
syntax, and let anybody who discovers otherwise send you a bug report
with a test case
Aug 18 16:29:12 <KragenSitaker> danc: nice hack
</pre>

The RFC3339 has a mandatory TIME portion of the DATE-TIME. Some vCard/iCalendar DATE-TIME stamps can omit the TIME. For instance, DTSTART, if that is a full day event, then you can omit the time. BDAY in vCard can be respresented by only a DATE. I like the idea of restricting the possible date formats, but i think that TIME should be optional, which it isn't in RFC3339. - [http://suda.co.uk/ brian suda]

RFC 3339 allows lowercase 't' and 'z' while XSD doesn't. Specifying RFC 3339 plus 'T' and 'Z' MUST be caps will make them the same. - [http://bitworking.org Joe Gregorio]

---

A few questions: asked by [[User:CharlesBelov|CharlesBelov]] 16:57, 24 Apr 2007 (PDT), answered by [[User:JamesCraig|JamesCraig]] on 15:58, 5 Jul 2007 (PDT).

# Would it make more sense for documenting the alternative codings pitting the abbr tag vs. other tags to be on this page? ''Answer: That documentation should go on the [[assistive-technology-abbr-results]] page.''
# Would using the title attribute of the abbr tag to encode the machine-readable date in fact cause a failure of WCAG 2.0 Accessibility? What about USA Section 508? It does appear to violate Technique for WCAG 2.0 [http://www.w3.org/TR/WCAG20-TECHS/#H28 H28: Providing definitions for abbreviations by using the abbr and acronym elements], although that is a supporting document and does not have the force of a guideline. ''Answer: Yes, it appears that is in violation of WCAG, 508, et al, so alternatives are being discussed on the [[assistive-technology-abbr-results]] page.''
# In order to maintain accessibility, would it make sense to enclose the machine-readable date in a span with a style of "display:none" instead of using the abbr tag? ''Answer: please refer to and add any suggestions to [[assistive-technology-abbr-results]].''
# For that matter, wouldn't you want to style such an abbr tag with text-decoration:none to hide that an abbr tag was used? Otherwise, visitors might cursor over the time, see the machine time, and be annoyed that their time was wasted or else be confused. And I don't think you can suppress the title from coming up if the human-readable time was inadvertently hovered. ''Answer: Microformats should not rely on CSS in order to work properly, but again, that discussion can be found here: [[assistive-technology-abbr-results]].''

== Code ==
The following regular expression (parsed VERBOSE) should break apart a datetime and cover many lightly broken cases seen in the wild. This has been tested under Python.

<pre><nowiki>
^
(?P<year>\d\d\d\d)
([-])?(?P<month>\d\d)
([-])?(?P<day>\d\d)
(
(T|\s+)
(?P<hour>\d\d)
(
([:])?(?P<minute>\d\d)
(
([:])?(?P<second>\d\d)
(
([.])?(?P<fraction>\d+)
)?
)?
)?
)?
(
(?P<tzzulu>Z)
|
(?P<tzoffset>[-+])
(?P<tzhour>\d\d)
([:])?(?P<tzminute>\d\d)
)?
$
</nowiki></pre>

== Other Proposals ==

=== strtime instructions as class names ===

Proposal by DavidLaban (alsuren on freenode) on 8 Jun 2008
It might be possible to have a slightly more readable/extensible/elegant format:
<pre><nowiki>
 16 March 1987 
</nowiki></pre>
Notes:
# Underscores are used to replace whitespace, because otherwise the the formatting string will be split into an unordered set of class attributes by many parsers (thanks go to bogdanlazarsb and gsnedders on irc for explaining this to me).
# Some subset of the placeholders should be chosen from those which are supported by both python http://docs.python.org/lib/module-time.html and php http://uk3.php.net/manual/en/function.strftime.php
# A name for the class should be decided upon. strtime might not be the best name.
# Measures should be taken to avoid the format string accidentally conflicting with other valid classes (In the above example, I have prefixed it with the string "format:")
# It might be sensible (when parsing) to strip excess whitespace from the format string and contents. This is not done in this example.
# Example python code follows.

<pre><nowiki>
date = (1987,03,16,0,0,0,0,0,0)
format = " %d %B %Y "
# To encode:
classes = ["strtime"]
encoded_format = "format:" + format.replace(' ', '_')
classes.append(encoded_format)
content = time.strftime(format, birthday)
# ... dump classes and content into your document however you want

# To decode (assuming that you have managed to extract class and format from the document already):
if "strtime" in classes:
possible_formats = [ item for item in classes if item.startswith('format:') ]
assert len(possible_formats) == 1
format = possible_formats[0].strip('format:').replace('_', ' ')
date = time.strptime(content, format)
</nowiki></pre>

==== problems with strtime proposal ====

# Possible abuse of the class attribute. microformats limit the use of the class attribute to marking up additional semantics about the data, not for (potentially) arbitrary processing/programming instructions
#* HTML 4.01 Recommendation [http://www.w3.org/TR/REC-html40/struct/global.html#adef-class defines] the <code>class</code> attribute as being "for general purpose processing by user agents". [[User:TobyInk|TobyInk]] 13:21, 8 Jun 2008 (PDT)
# Requires authors to think like programmers. The larger problem is that the proposal asks web authors to think like programmers, which severely limits the number of web authors which will be able to use the technique, since the vast majority of web authors are ''not'' programmers and have never heard of "strtime", whereas most authors (even people) on the web have seen dates like 2005-06-20 and easily understand what they mean.

In general, any publishing method that requires the author to think like a programmer is a non-starter. It is a much more of a barrier than simply using ISO8601/RFC3339, and that barrier is a far worse tradeoff than the duplication / DRY violation compromise.
[[User:Tantek|Tantek]] 09:52, 8 Jun 2008 (PDT)

* Another problem: if %A/%a/%B/%b are allowed, this raises potential problems with internationalisation. Will parsers be required to understand the names and abbreviations for days and months in potentially hundreds of different languages? [[User:TobyInk|TobyInk]] 14:09, 8 Jun 2008 (PDT)

=== Machine-data in class===
The BBC ([http://microformats.org/discuss/mail/microformats-dev/2008-June/000552.html uf-dev archive, 20/06/08, "Using class for non-human data"]) has proposed as an alternative to the empty span and title solution to use the class name in the following way:
<pre><nowiki>
10 o'clock on the 10th
</nowiki></pre>
Pros:
* Allows data to be represented in a "non-harmful" way. Will not be read aloud by screenreaders or seen as tooltips.
* Minimises mark-up used.
* Arguably more semantic than use of "title" attribute for non-human data.

Cons:
* data in the class attribute has already been discussed numerous times in the mailing list over the years and rejected and documented as an [[anti-pattern]] - captured [http://microformats.org/wiki?title=anti-patterns&diff=24271&oldid=24270 on the wiki this past January 2008].
* Possible misuse of class attribute, although as noted previously, the HTML spec states "for general purpose processing by user agents".
* The class attribute has been adopted by the broader web design community to "subclass" element semantics, and to layer additional semantics. To date, microformats has followed this existing practice developed by modern web designers ("paving the cow-paths"). This use of class for data is outside all current practices.

Discussion:
* This proposal smells icky, but I can't quite put my finger on why. Considered objectively, it does seem to be the least harmful solution proposed so far. [[User:TobyInk|TobyInk]] 06:06, 21 Jun 2008 (PDT)
* I really like it, especially given the HTML4 spec gives this as an IMO perfectly valid use (on both id and class, with the following examples given in the id section: "identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc."). Clean and simple. [[User:Dracos|Dracos]] 03:53, 23 Jun 2008 (PDT)
* I suggest dropping the redundant 'data-' prefix, unless someone can suggest a feasible case with two time-stamps requiring different prefixes. The proposal then becomes [http://www.robertnyman.com/2008/04/28/do-we-really-need-microformats/#comment-263408 one I've made before] [[User:AshSearle|AshSearle]]
** Valid class names cannot begin with a number, so a date needs some sort of letter prefix. It's sensible to make this prefix meaningful and reusable in some way. [[User:Phae|Phae]]
*** They can't in CSS, but they can in (X)HTML. http://examples.tobyinkster.co.uk/numeric-classes.html [[User:TobyInk|TobyInk]] 06:53, 24 Jun 2008 (PDT)
** Not to advocate too strongly for designing for parsers (generally a bad idea), *but* having a 'data-' prefix on a class name would make identifying data orders of magnitude easier for parsing. Otherwise, how do we know what's data and what's just another class name for some other purpose? [[User:DrewMcLellan|Drew]]
** A 'data-' prefix would help authors tasked with maintaining or reviewing a page to understand the purpose of a class name that may have been applied by another author. The data prefix communicates very simply that the class name is precisely that, data. Therefore the value is less likely to be accidentally removed or changed, making for a more robust design. [[User:DrewMcLellan|Drew]]
*** I concede - regardless of whether it's valid (X)HTML / CSS - a prefix is needed to distinguish data values from genuine content. ISO 8601 allows date-time to be as simple as "2004", which could easily be misinterpreted. e.g. if a CMS outputs product model numbers into the class attribute for some other purpose. --[[User:AshSearle|AshSearle]] 01:42, 25 Jun 2008 (PDT)
* -1 [[User:Tantek|Tantek]]. I'm vehemently opposed to putting data in the class attribute. We ''must'' find better alternatives. We must not go down the path of invisible (dark) (meta)data - IMHO that [[principle]] is inviolable for microformats.
** [[User:JakeArchibald|JakeArchibald]] If you're so opposed, it'd be useful to see some justification.
*** See above cons. Already discussed/rejected many times in the history of microformats discussions. In short, quit wasting time on old ground. Abuses class attribute, or if you prefer, introduces a *new* use of the class attribute, unlike microformats to-date which have simply made use of a well established semantic of the class attribute. And worst of all, completely violates the visible data [[principle]]. Rejectable on that alone.
**** The fact that something has been discussed and rejected before is not sufficient grounds for dismissing it out of hand once additional research and thinking has taken place. The <abbr> datetime pattern arguably abused the title attribute and introduced a new use of the title attribute. In the example given (<code><nowiki>10 o'clock on the 10th</nowiki></code>), the data is presented as "10 o'clock on the 10th" - very visible. Yes, of course, it's possible to abuse this proposed pattern, and hide the data, but the same can be said of the abbr pattern or even the class pattern given CSS's display:none property. Experience shows that in most cases, people ''won't'' abuse the pattern to hide data, as they actually ''want'' to show the data on their pages. [[User:TobyInk|TobyInk]] 13:52, 24 Jun 2008 (PDT)
**** It's not an abuse of the class attribute according to the HTML spec. as I read it. Whereas using title for non-human data is (the spec says audio agents may read it aloud, for example). If it's a new use, it's one the writers of HTML4 considered, so it wasn't new to them. [[User:Dracos|Dracos]] 03:38, 25 Jun 2008 (PDT)
** Relevant princeples are 'humans first, machines second', and 'visible data is ''better'''. These are ''preferences'', not inviolable principles. Besides, the existing datetime spec doesn't adhere to these principles anyway: prioritising humans first, <code><nowiki>let's discuss this at the next meeting</nowiki></code> should be marked up as <code><nowiki>let's discuss this at the <abbr title="28th June 2008 at 3:15pm">next meeting</nowiki></code>. There's a conflict between human- and machine-readable dates. It makes more sense to 'hide' the machine-readable data in the only attribute available to us: <code>class</code>. --[[User:AshSearle|AshSearle]] 03:02, 25 Jun 2008 (PDT)
*** Indeed - by their nature, ''principles'' are ''generalisations'', and while broadly useful, usually have exceptions. After experience, the microformats community is beginning to see some of these. Human vs machine dates is the one gathering the most interest at the moment, largely thanks to <abbr class="help" style="border-bottom:1px dotted" title="the Web Standards Project">WaSP</abbr> and auntie, but I think other properties which will probably emerge as exceptions to the general microformats principles are hReview's <code>type</code> property, and the its namesake subproperty for hCard's <code>tel</code>, <code>email</code> and <code>adr</code> (and <code>label</code>?) properties. [[User:TobyInk|TobyInk]] 12:51, 25 Jun 2008 (PDT)

==== Experimental Parser Support ====

[http://buzzword.org.uk/cognition/ Cognition 0.1 alpha 10] will include experimental support for this pattern, and the [http://srv.buzzword.org.uk Cognition web service] already does. Notes:
* Support is ''opt-in''. Publishers must explicitly request support for the pattern, by including a [[profile-uris|profile URI]] of <code><nowiki>http://purl.org/uF/pattern-data-class/1</nowiki></code> in their document head.
* Support is not limited to date-time properties, but any microformat properties.
* data-X classes must use percent-encoding to encode spaces and other characters not allowed in class names.
* The data-X class must be found on the same element as the microformat property class. That is, you cannot use: <pre><nowiki>10 o'clock</nowiki></pre>
<ul><li>Multiple data-X classes may occur on the same element. When these are found, the longest string is used. This allows for: <pre><nowiki>The 10th</nowiki></pre> which may be useful for styling or other non-microformat purposes.</li>
<li>Can be combined with value excerpting. e.g. <pre><nowiki>

The concert will be held on
the 4th of August
starting at
7:30pm precisely.

</nowiki></pre></li></ul>

=== date and time separation using value excerption ===

==== summary ====
By specifying a more precise parsing of the use of "value" excerption inside all datetime properties (e.g. dtstart, dtend, published, updated etc.), dates and times can be marked up separately, thus reducing/minimizing (and potentially eliminating) the readability issues that come with compound ISO8601 datetimes.

==== introductory example ====
The sentence:

<pre><nowiki>
The weekly dinner is tonight at 6:30pm.
</nowiki></pre>

would be marked up as:

<pre><nowiki>
The weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
at <abbr class="value" title="18:30">6:30pm</abbr>.
</nowiki></pre>

==== advantages ====
* re-uses the readable [[abbr-date-pattern]]
* identifies a similarly readable abbr-time-pattern.
* minimizes DRY violation distance, keeps machine data on exactly the same element as the respective human data
** even better than [[abbr-datetime-pattern]] does, which, in practice from experience often required specifying the date in machine readable form on the human readable time (separate from the human readable date).
* introduces no new class names - [[principle]] of minimal invention
* introduces no new use of the class attribute - principle of minimal invention again
* introduces no new syntax ([[datetime-design-pattern#problems_with_strtime_proposal|see above]] about any publishing method that requires the author to think like a programmer being a non-starter, and introducing new syntax almost always requires authors to think like programmers).
* and most importantly, introduces no dark data.

==== issues ====
Some potential issues were raised in IRC, and it helps to document/resolve them so that they are not brought up repeatedly.
* [[http://rbach.priv.at/Microformats/IRC/2008-06-24#T163114 Does this sufficiently address the concerns raised with the current use of abbr-pattern?]]
*# The [[abbr-date-pattern]], as documented and explained by [[User:Adactio|Jeremy Keith]] is just fine (in contrast to the [[abbr-datetime-pattern]]).
*# Similar to the [[abbr-date-pattern]], this proposal implies/introduces the abbr-time-pattern, which is similarly acceptable.
** That's not a complete coverage of the ABBR complaints. Separating into 2008-06-07 and 18:03 improves the ability for humans to consume the data, but still exposes data through tooltips and speech in formats that the publisher did not choose to use. --[[User:BenWard|BenWard]] 04:52, 25 Jun 2008 (PDT)
*** if a site publisher wishes to customize the presentation of tooltips, they can do so with a nested span with title.
**** That proposes extraneous mark-up maintain the publisher's wish not to have a tool-tip in the first place. I object to a microformat pattern requiring an immediate work-around to meet publisher's desires. It goes against ‘Humans first…’. --[[User:BenWard|BenWard]] 09:09, 30 Jun 2008 (PDT)
** Additionally, it does not solve the semantic misuses of ABBR. That ‘tonight’ is ever a textual, human abbreviation of ‘2008-06-24’ is not accepted, nor is it possible to use this mark-up and always maintain proper sentences with the expanded form. e.g. <code>it's my <abbr class="bday" title="2005-06-20">birthday today</abbr>!</code> becomes ‘it's my 2005-06-20!’. That content remains broken by the continued stretch of ABBR semantics. --[[User:BenWard|BenWard]] 04:52, 25 Jun 2008 (PDT)
*** I concur. We need to explore a solution that allows authors to choose what mark-up they use to best fit their implementation. Publishing practices and desires show us that authors are not willing to compromise the semantics of abbr. [[User:Phae|Phae]] 04:30, 27 Jun 2008 (PDT)
* [[http://rbach.priv.at/Microformats/IRC/2008-06-24#T163435 That's getting pretty complicated]]
** Much less complicated than inventing yet another syntax ( " { ... } " ???? ) that web authors would have to learn.
*** But it's all in one place, rather than spreading it out.
**** The spreading it out is what current content publishing practices do already! It is much more important to map the machine data as close to the existing publishing practice as possible, than to try to "put it all in one place". The "put it all in one place" way of thinking is why people ended up sticking so much invisible metadata in the head of the document, which we know fails.
* Audio rendition of such titles can be nonsensical - "The weekly dinner is two thousand and eight dash zero six dash twenty four at eighteen thirty."

==== content requirements ====
Some requirements which enhance both human readability, ''and'' machine parsability (best of both) :
* date value excerpts MUST use hyphen separators. E.g. 2008-06-24. Not ok:20080624.
* time value excerpts MUST use colon separators (seconds optional, implied :00 if absent). E.g. 18:30 or 18:30:00. Not ok:183000.
* timezone value excerpts MUST use leading plus or minus and NO colon separator. E.g. -0700. Not ok:-07:00.

==== derivation ====
It's important to document the derivation/background of a brainstorm/proposal as it allows others to see some of the thinking that went into it, and avoid having to rediscuss alternatives already considered, and helps provide understanding as to why aspects of the design are as they are.
===== example with datetime =====
Here is a short code example:
<pre><nowiki>
the weekly dinner is tonight at 2008-06-24T18:30
</nowiki></pre>
===== example with abbr datetime =====
However that's not the easiest to read, nor do most people publish that as human visible text, so per the abbr-datetime pattern:
<pre><nowiki>
the weekly dinner is tonight at <abbr class="dtstart" title="2008-06-24T18:30">6:30pm</abbr>
</nowiki></pre>

which has raised two issues:
# When "2008-06-24T18:30" is inspected by a human reading a tooltip, or spoken by a screen reader, it's not the most understandable thing (precise citation needed, perhaps an mp3 with screen reader used version info).
# There is a non-local violation of DRY (which IMHO is a worse problem, as it leads to worse data quality -[[User:Tantek|Tantek]]). That is, the "date" information is now not only in the text twice (as it was before), but those two instances of the date information are not on the same element, which makes it worse. That is, "tonight" is in the prose, ''outside'' of the element with the precise date "2008-06-24".

In analysis of examples of event information on the web, the date and time are often published in separate elements, often for display purposes.

Thus it is this existing content publishing practice which leads to this brainstorm proposal, to essentially to introduce a date and time value excerption longhand.

(Initially [http://rbach.priv.at/Microformats/IRC/2008-06-21#T181634 Tantek's idea that he bounced off Jeremy Keith] ([http://rbach.priv.at/Microformats/IRC/2008-06-24#T124652 similar idea conceived by Drew independently]) was to [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161819 introduce new classes "datevalue", "timevalue"] and "tzvalue" for this purpose, but [http://rbach.priv.at/Microformats/IRC/2008-06-24#T171603 Bob Jonkman pointed out] that HTML5's time parsing algorithm enables a single <nowiki><time></nowiki> element to contain dates or times (with or without timezone) without having to explicitly say whether the value contains dates or times (with or without timezone). [http://rbach.priv.at/Microformats/IRC/2008-06-24#T171723 Bob then proposed] that thus all was needed was a single new "datetime" class name. This was the key realization that allowed minimal invention. Tantek pointed out that since from the type of property we already know it is a datetime, [http://rbach.priv.at/Microformats/IRC/2008-06-24#T171835 there was no need for even one new class name], that we could simply re-use "value" excerption, and simply more precisely specify the semantics/parsing in the case of datetime properties.)

===== example with new date and time value excerpts =====
Thus we markup the date and time separately, as value excerpts, using the [[abbr-date-pattern]] and an implied parallel abbr-time-pattern:

<pre><nowiki>
The weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
at <abbr class="value" title="18:30">6:30pm</abbr>.
</nowiki></pre>

===== separate subtrees =====
The proposal also allows setting the date and time in separate element subtrees as well, which may be necessary for some document structures:

<pre><nowiki>
the weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
at <abbr class="value" title="18:30">6:30pm</abbr>.
</nowiki></pre>

Note the two instances of dtstart, one of which sets the date for the dtstart, and the other of which sets the time.

The idea being, when a parser sees a datetime property (e.g. dtstart) with a value excerpt, that it only "set" the component of its full value that is specified by the value excerpt (e.g. the date), and that if lacking a complete datetime, it continue to parse additional instances of that datetime property for the remaining component(s) (e.g. the time).

Of course this only works for singular properties, but fortunately all instances of datetime properties so far are singular, so this works.

===== reusing date data for multiple datetime properties =====
This also provides a *very* convenient way to re-use the same date information for start and end, e.g. expanding the example:

<pre><nowiki>
the weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
from <abbr class="value" title="18:30">6:30</abbr> -
<abbr class="value" title="20:30">8:30pm</abbr>.
</nowiki></pre>

Note what just happened. we just eliminated another duplication of date information by reusing the start *date* information for the end *date* information and *only* specifying the end *time* information separately for the two properties.

Reducing the duplication (or triplication) of such data helps to reduce the chances of (even inadvertent) data corruption/drift/divergence among any duplicates.

===== time zones =====
There are a few choices for timezones.
# Simply include the time zone information as part of the time "value". E.g. <code><nowiki><abbr class="value" title="18:30-0700">6:30pm</abbr></nowiki></code>
# Or use another value excerpt for the timezone (was: <del>introduce the class name "tzvalue"</del>) E.g. <code><nowiki><abbr class="value" title="18:30">6:30pm</abbr> <abbr class="value" title="-0700">PDT</abbr></nowiki></code>
# Or allow both and let web authors decide. This is the current leaning.
#* if web authors want to specify timezone as part of the time (first example above), they can,
#* or if web authors visibly publish the timezone separately (second example above), then they can mark that up.
#* or if web authors wish to omit timezone information, they can do so as well, as most do today. In practice this works fine, as it creates a "floating" time which works fine in far more than the 80/20.

(more to come, documenting [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161740 from IRC logs])

==== discussion ====
Opening up a discussion section even though documentation [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161740 from IRC logs] is still in progress. :)

* regarding the [[datetime-design-pattern#advantages|advantage]] of "and most importantly, introduces no dark data."
** "Dark data" is sometimes what publishers *want* to publish. To use the example of TV schedules which kick started the renewed discussion in this area, publishers will often not want to display the date. For instance, if a page entitled "Tomorrow's TV" and containing 300 different programmes marked up with <code>dtstart</code>, it is superfluous to explicitly display the date for each one. With this proposed solution the [[include|include pattern]] could be used to include the date into each vevent, but a visible link to the date on each programme would simply be confusing. Sometimes it just makes sense to hide some of the information you're publishing as a microformat - because the information you want to make explicit to parsers can be inferred from context by humans, or is more appropriately displayed at a different level of granularity for machines and humans. [[User:TobyInk|TobyInk]] 14:26, 24 Jun 2008 (PDT)
*** It doesn't matter whether publishers *want* to publish dark data or not. Invisible data always leads to poorer quality data. Publishers publish all kinds of invisible metadata in the heads of documents etc. because they want to, but their desire doesn't stop the data from becoming obsolete, diverging from the actual visible data etc. The quality of the data matters more than any publishers wish(es) of publishing in a specific format, or in a hidden way. In the example you gave, using the include pattern in that way would not result in any visible links, but merely empty include anchors. It never makes any sense to actually hide "some of the information you're publishing as a microformat", because historically that always results in some loss of data quality over time and thus the microformats [[principle]] of visible data instead of invisible metadata. [[User:Tantek|Tantek]] 14:32, 24 Jun 2008 (PDT)
**** All microformats hide ''some'' data. In the example <code><nowiki>01632 960123</nowiki></code>, the information that the long string of numbers represents a telephone number is invisible. And making it visible (<code><nowiki>Tel: 01632 960123</nowiki></code>) violates DRY. It's just a matter of where to draw the line.
***** That statement makes the mistake of conflating *type* data and *content* data. "tel" is not content data, just as <nowiki></nowiki> is not content data. It's markup, indicating the type of the data. Markup (type data) being invisible to the user has worked just fine. Content (content data) being invisible to the user is the problem of dark data. Or rather, if you think that everything is data, then you really should be spending time developing in a system that is built on that assumption, e.g. RDF, rather than microformats, which are built on HTML, and the clear separation of type of data (HTML elements, microformats properties) and content data (inner text, text attribute values).
****** My point is that there isn't a ''distinction'' between the two, but a ''continuum''. The choice of where to draw the line is never a clear one and always somewhat arbitrary. The vCard standard could quite easily have ended up with separate "TEL", "FAX" and "CELL" properties, in which case hCard would have ended up with <code><nowiki><foo class="tel"></nowiki></code>, <code><nowiki><bar class="fax"></nowiki></code> and <code><nowiki><baz class="cell"></nowiki></code>. Going the other way, they could have stored e-mail addresses as mailto: URLs, and then hCard would have <code><nowiki><a class="url" href="mailto:quux@example.com"></nowiki></code>. They chose the way they did, and as a result in hCard the distinction between a mailto: URI and an http: URI is largely invisible (in most circumstances only obvious by looking at the status bar when hovering), but the distinction between a telephone number and a fax number is visible. But that wasn't the only possible (nor the only reasonable) outcome.

=== HTML 5 <code><time></code> Element ===

[http://microformats.org/wiki/hcalendar-issues#html5-time-element See hCalendar issues]

=== Plain Old English alternative to ISO date ===

Example (in English):

<pre>
<abbr title="January 25th, 2008" class="dstart" lang="en-us">1/25</abbr>
</pre>

<pre>
January 25th, 2008
</pre>

If <code>lang="en-us"</code>, the format of the date used in the <code>title</code> attribute must conform to [http://www.ego4u.com/en/cram-up/vocabulary/date/written dates writing rules in American English].

Example (in French):

<pre>
<abbr title="25 Janvier 2008" class="dstart" lang="fr">25/1</abbr>
</pre>

If <code>lang="fr"</code>, the format of the date used in the <code>title</code> attribute must conform to date writing rules in French.

====Benefits====

* Human-hearable: should work nicely with screen readers (to be tested).
* Human-readable
* Compliance with semantics of abbr.
* Very easy to use by HTML human authors.
* DRY compliant if HTML human authors are willing to write in correct English

====Drawbacks====

* Locale-specific parsing logic.

====Notes====

* Could work alongside with the existing [[datetime-design-pattern]]: if ISO date parsing fails, try parsing the title as a human-readable plain old English/French/... date according to the locale.

== See Also ==

* [[Main_Page#Design_Patterns|All microformat design patterns]]
* [[abbr-design-pattern]] is used by [[datetime-design-pattern]]
* [[date-design-pattern]] is a subset of [[datetime-design-pattern]]
* HTML 4.01 definition of <code><[http://www.w3.org/TR/REC-html40/struct/text.html#edef-ABBR abbr]></code> element
* RFC [http://www.faqs.org/rfcs/rfc3339.html 3339]: Date and Time on the Internet: Timestamps
* W3C: [http://www.w3.org/TR/NOTE-datetime Note on Datetimes]
* Markus Kuhn: [http://www.cl.cam.ac.uk/~mgk25/iso-time.html A summary of the international standard date and time notation]
* Wikipedia: [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]

datetime-design-pattern

2008-07-01T16:21:35Z

Guillaume Lebleu: /* HTML 5 <code><time></code> Element */

<h1> Datetime Design Pattern </h1>
This is a page for exploring a datetime design pattern.

{{TOC-right}}

== Purpose ==
* Use the [[datetime-design-pattern]] to make datetimes that are human readable also formally machine readable.

== Practical Need ==
* This design pattern arose as a result of solving the practical need for human readable dates for [[hcalendar|hCalendar]].

== How to use it ==
* enclose the human-friendly datetime that you want to make machine readable with <code><abbr></code>
* as per the [[class-design-pattern]], add the appropriate <code>class</code> attribute to the <code>abbr</code> element
* add a <code>title</code> attribute to the <code>abbr</code> element with the machine readable [[iso-8601|ISO8601]] datetime or date as the value

==Current uses==

The pattern, which is now available as part of [[hAtom]], [[hcalendar|hCalendar]], [[hcard|hCard]] and [[hreview|hReview]], is:

:<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SS+ZZ:ZZ">Date Time</abbr></pre>

where foo is the semantic classname which is being applied to this date/time, the title of the <abbr> is an ISO 8601 date/time, with an appropriate level of specificity, and "Date Time" is a human-friendly representation of the same date/time.

An alternative, if you are using UTC-based timestamps, would be:

:<pre><abbr class="foo" title="YYYY-MM-DDTHH:MM:SSZ">Date Time</abbr></pre>

with a single "Z" as per [[iso-8601|ISO 8601]]

Ruby: An easy way to get this format from a DateTime is this:
:<pre>DateTime.now.to_s</pre>

== Profile of ISO8601 ==

Any [[microformat]] using the date-time-design pattern {{should}} use a profile of [[iso-8601|ISO8601]]. There are currently two widely used profiles which {{should}} be reused.

* RFC 3339
* [http://www.w3.org/TR/NOTE-datetime W3C Note on Datetimes]

==Accessibility issues==

Note: Some accessibility issues have been raised([http://www.webstandards.org/2007/04/27/haccessibility/]) with Datetime Design Pattern, and concerns that its use could breach WCAG accessibility guidelines, that are being addressed as part of the [[abbr-design-pattern-issues]] discussion. Possible change recommendations may follow after the accessibility testing is complete. The accessibility concerns are considerably lessened, even eliminated when using the [[date-design-pattern]], a subset of the [[datetime-design-pattern]].

== Discussion ==
This pattern is likely to be highly resuable.

--[[User:RyanKing]]

Can this not be viewed as a microformat in itself?

--[[User:DimitriGlazkov]]

It could, but inventing a microformat for the sake of inventing a microformat is against the microformat principles.
If there is a specific real world problem (and uses cases) that such an elemental microformat would solve, then it would be worth considering.

Until then it is best to keep the <abbr> datetime concept merely as a microformat design pattern, to be used in _actual_ microformats that have a demonstrated practical need.

-- [http://tantek.com/log/ Tantek]

Excerpt from #microformats Aug 18th. Please edit!

<pre>
Aug 18 15:16:14 <Tantek> DanC, what do you think of RFC3339?
Aug 18 15:17:14 <Tantek> ISO8601 subset
Aug 18 15:17:19 <DanC> Date and Time on the Internet: Timestamps http://www.ietf.org/rfc/rfc3339.txt
Aug 18 15:17:30 <DanC> Klyne is a good guy. I wonder if I talked with him about this.
Aug 18 15:17:32 <Tantek> compat with W3C-NOTE-DATETIME
Aug 18 15:17:50 <Tantek> compat with xsd:dateTime
Aug 18 15:17:57 <Tantek> it's a strict intersection subset
Aug 18 15:17:59 <DanC> I consider W3C-NOTE-DATETIME obsoleted by XML Schema datatype-- yeah.. xsd:dateTime
Aug 18 15:18:32 <Tantek> compare/contrast normatively using xsd:dateTime vs. RFC3339
Aug 18 15:18:41 <Tantek> note: Atom 1.0 chose RFC3339
Aug 18 15:18:50 <Tantek> i would like input from the microformats community on this
Aug 18 15:19:27 <DanC> in what context are you evaluating RFC 3339?
Aug 18 15:19:28 <jcgregorio> http://bitworking.org/news/Date_Constructs_in_the_Atom_Syndication_Format
Aug 18 15:21:24 <DanC> which microformat is the question coming from, Tantek ?
Aug 18 15:23:31 <DanC> " The grammar element time-second may have the value "60" at the end of
Aug 18 15:23:31 <DanC> months in which a leap second occurs" The XML Schema WG is in the 27th level of
leap-second-hell for the past few months, I gather.
Aug 18 15:24:21 <DanC> yeah... here's the scary bit: " Leap seconds cannot be predicted far into the
future. The
Aug 18 15:24:21 <DanC> International Earth Rotation Service publishes bulletins [IERS] that
Aug 18 15:24:21 <DanC> announce leap seconds with a few weeks' warning."
Aug 18 15:26:03 <Tantek> DanC, which microformats? any/all that use datetime fields.
Aug 18 15:26:36 <DanC> hard to give useful advice, then.
Aug 18 15:26:58 <DanC> I expect they'll use datetime fields for different things that have different
cost/benefit trade-offs
Aug 18 15:27:26 <DanC> do you know of any particular differences that matter to anybody?
Aug 18 15:56:43 <KragenSitaker> RFC3339 suggests -07:00, which seems like an improvement over -0700 anyway
Aug 18 15:56:49 <Tantek> Kragen, agreed
Aug 18 15:57:01 <Tantek> RFC3339 is certainly preferable to the ISO8601 subset in iCalendar
Aug 18 16:05:57 <DanC> Tantek's right, Kragen; iCalendar looks like it solves the local timezone
problem but doesn't.
Aug 18 16:06:14 <DanC> and it's true that there's no standard solution to the local timezone problem
Aug 18 16:06:39 <Tantek> so instead of appearing to solve the problem but not solving it, we chose to
provide the ability to *approximate* the local timezone using e.g. "-07:00"
Aug 18 16:06:49 <DanC> the simplest thing is to have people use Z time in hCalendar. But I gather
that's unacceptably unusable?
Aug 18 16:07:35 <Tantek> DanC, yes, the simplest thing is to have everyone use UTC Z
Aug 18 16:07:38 <Tantek> However
Aug 18 16:07:50 <Tantek> it is not *nearly* as usuable/verifiable
Aug 18 16:07:55 <Tantek> as -07:00 etc.
Aug 18 16:08:02 <Tantek> hence the decision to go with the latter
Aug 18 16:08:12 <Tantek> some degree of human verifiability is important here
Aug 18 16:14:21 <Tantek> DanC, my perception is that RFC3339 is a subset
Aug 18 16:17:00 <DanC> time-numoffset = ("+" / "-") time-hour ":" time-minute
Aug 18 16:17:34 <DanC> ok, then I can't see any differences. (modulo recent leap seconds issues that
may affect xsd:dateTime )
Aug 18 16:18:07 <Tantek> would be interesting to know why Atom 1.0 chose RFC3339 over xsd:dateTime
Aug 18 16:18:21 <Tantek> if there was a "real" reason or if it was arbitrary / coin-flip.
</pre>

Here's an exhaustive [http://www.imc.org/atom-syntax/mail-archive/msg13103.html comparison] from ndw. I think xsd:dateTime also allows unqualified local times, while RFC3339 allows only UTC with no known timezone (-00:00). In the end, Atompub followed the advice of [http://www.imc.org/atom-syntax/mail-archive/msg13244.html Sam Ruby] and [http://www.imc.org/atom-syntax/mail-archive/msg13248.html Scott Hollenbeck], our area director. Atom dates make some additional restrictions on RFC3339, such as uppercase T and Z characters for compatibility with xsd:dateTime, RFC3339, W3C-DTF, and ISO8601. --[http://franklinmint.fm Robert Sayre]

<pre>
Aug 18 16:18:43 <KragenSitaker> rfc3339 is pretty short.
Aug 18 16:19:36 <Tantek> DanC, BTW, which came first? REC for xsd:dateTime or RFC3339?
Aug 18 16:19:50 <DanC> RFC3339 is dated July 2002 ...
Aug 18 16:19:54 <KragenSitaker> Right --- and you might be able to understand xsd:dateTime without
reading all of xml schema, you wouldn't be confident of it
Aug 18 16:20:25 <DanC> W3C Recommendation 28 October 2004 ... but that's 2nd ed...
Aug 18 16:20:47 <DanC> W3C Recommendation 02 May 2001
Aug 18 16:22:10 <DanC> I don't see a BNF in http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime ...
Aug 18 16:22:43 <KragenSitaker> yeah, appendix D of the current xml schema datatypes document seems
a little scanty, actually
Aug 18 16:23:28 <DanC> ah... 2nd ed of http://www.w3.org/TR/xmlschema-2/#date is much more
explicit about syntax.
Aug 18 16:23:30 <KragenSitaker> it's 1100 words but still doesn't give any examples
Aug 18 16:23:35 <DanC> still, it's given in prose and not BNF
Aug 18 16:24:17 <KragenSitaker> sections 3.2.9 through 3.2.14 seem to be the relevant ones around #date
Aug 18 16:24:29 <KragenSitaker> which is another 2200 words
Aug 18 16:24:42 <DanC> wow... they changed the canonical form of date from always-Z to
timezone-allowed between 1st edition and 2nd edition
Aug 18 16:25:01 <Tantek> Kragen, DanC, these are very good analyses
Aug 18 16:25:21 <Tantek> could I ask you to summarize the pros/cons for each in a new section at
end of http://microformats.org/wiki/datetime-design-pattern
Aug 18 16:25:22 <Tantek> ?
Aug 18 16:25:58 <KragenSitaker> rfc 3339 is 4000 words, excluding the last two pages of boilerplate.
Aug 18 16:26:31 <KragenSitaker> so it's actually longer than the datetime-relevant parts of XSD but it
seems much more rigorous and clear
Aug 18 16:28:37 <DanC> my advice is: normatively cite both, and claim they specify the same
syntax, and let anybody who discovers otherwise send you a bug report
with a test case
Aug 18 16:29:12 <KragenSitaker> danc: nice hack
</pre>

The RFC3339 has a mandatory TIME portion of the DATE-TIME. Some vCard/iCalendar DATE-TIME stamps can omit the TIME. For instance, DTSTART, if that is a full day event, then you can omit the time. BDAY in vCard can be respresented by only a DATE. I like the idea of restricting the possible date formats, but i think that TIME should be optional, which it isn't in RFC3339. - [http://suda.co.uk/ brian suda]

RFC 3339 allows lowercase 't' and 'z' while XSD doesn't. Specifying RFC 3339 plus 'T' and 'Z' MUST be caps will make them the same. - [http://bitworking.org Joe Gregorio]

---

A few questions: asked by [[User:CharlesBelov|CharlesBelov]] 16:57, 24 Apr 2007 (PDT), answered by [[User:JamesCraig|JamesCraig]] on 15:58, 5 Jul 2007 (PDT).

# Would it make more sense for documenting the alternative codings pitting the abbr tag vs. other tags to be on this page? ''Answer: That documentation should go on the [[assistive-technology-abbr-results]] page.''
# Would using the title attribute of the abbr tag to encode the machine-readable date in fact cause a failure of WCAG 2.0 Accessibility? What about USA Section 508? It does appear to violate Technique for WCAG 2.0 [http://www.w3.org/TR/WCAG20-TECHS/#H28 H28: Providing definitions for abbreviations by using the abbr and acronym elements], although that is a supporting document and does not have the force of a guideline. ''Answer: Yes, it appears that is in violation of WCAG, 508, et al, so alternatives are being discussed on the [[assistive-technology-abbr-results]] page.''
# In order to maintain accessibility, would it make sense to enclose the machine-readable date in a span with a style of "display:none" instead of using the abbr tag? ''Answer: please refer to and add any suggestions to [[assistive-technology-abbr-results]].''
# For that matter, wouldn't you want to style such an abbr tag with text-decoration:none to hide that an abbr tag was used? Otherwise, visitors might cursor over the time, see the machine time, and be annoyed that their time was wasted or else be confused. And I don't think you can suppress the title from coming up if the human-readable time was inadvertently hovered. ''Answer: Microformats should not rely on CSS in order to work properly, but again, that discussion can be found here: [[assistive-technology-abbr-results]].''

== Code ==
The following regular expression (parsed VERBOSE) should break apart a datetime and cover many lightly broken cases seen in the wild. This has been tested under Python.

<pre><nowiki>
^
(?P<year>\d\d\d\d)
([-])?(?P<month>\d\d)
([-])?(?P<day>\d\d)
(
(T|\s+)
(?P<hour>\d\d)
(
([:])?(?P<minute>\d\d)
(
([:])?(?P<second>\d\d)
(
([.])?(?P<fraction>\d+)
)?
)?
)?
)?
(
(?P<tzzulu>Z)
|
(?P<tzoffset>[-+])
(?P<tzhour>\d\d)
([:])?(?P<tzminute>\d\d)
)?
$
</nowiki></pre>

== Other Proposals ==

=== strtime instructions as class names ===

Proposal by DavidLaban (alsuren on freenode) on 8 Jun 2008
It might be possible to have a slightly more readable/extensible/elegant format:
<pre><nowiki>
 16 March 1987 
</nowiki></pre>
Notes:
# Underscores are used to replace whitespace, because otherwise the the formatting string will be split into an unordered set of class attributes by many parsers (thanks go to bogdanlazarsb and gsnedders on irc for explaining this to me).
# Some subset of the placeholders should be chosen from those which are supported by both python http://docs.python.org/lib/module-time.html and php http://uk3.php.net/manual/en/function.strftime.php
# A name for the class should be decided upon. strtime might not be the best name.
# Measures should be taken to avoid the format string accidentally conflicting with other valid classes (In the above example, I have prefixed it with the string "format:")
# It might be sensible (when parsing) to strip excess whitespace from the format string and contents. This is not done in this example.
# Example python code follows.

<pre><nowiki>
date = (1987,03,16,0,0,0,0,0,0)
format = " %d %B %Y "
# To encode:
classes = ["strtime"]
encoded_format = "format:" + format.replace(' ', '_')
classes.append(encoded_format)
content = time.strftime(format, birthday)
# ... dump classes and content into your document however you want

# To decode (assuming that you have managed to extract class and format from the document already):
if "strtime" in classes:
possible_formats = [ item for item in classes if item.startswith('format:') ]
assert len(possible_formats) == 1
format = possible_formats[0].strip('format:').replace('_', ' ')
date = time.strptime(content, format)
</nowiki></pre>

==== problems with strtime proposal ====

# Possible abuse of the class attribute. microformats limit the use of the class attribute to marking up additional semantics about the data, not for (potentially) arbitrary processing/programming instructions
#* HTML 4.01 Recommendation [http://www.w3.org/TR/REC-html40/struct/global.html#adef-class defines] the <code>class</code> attribute as being "for general purpose processing by user agents". [[User:TobyInk|TobyInk]] 13:21, 8 Jun 2008 (PDT)
# Requires authors to think like programmers. The larger problem is that the proposal asks web authors to think like programmers, which severely limits the number of web authors which will be able to use the technique, since the vast majority of web authors are ''not'' programmers and have never heard of "strtime", whereas most authors (even people) on the web have seen dates like 2005-06-20 and easily understand what they mean.

In general, any publishing method that requires the author to think like a programmer is a non-starter. It is a much more of a barrier than simply using ISO8601/RFC3339, and that barrier is a far worse tradeoff than the duplication / DRY violation compromise.
[[User:Tantek|Tantek]] 09:52, 8 Jun 2008 (PDT)

* Another problem: if %A/%a/%B/%b are allowed, this raises potential problems with internationalisation. Will parsers be required to understand the names and abbreviations for days and months in potentially hundreds of different languages? [[User:TobyInk|TobyInk]] 14:09, 8 Jun 2008 (PDT)

=== Machine-data in class===
The BBC ([http://microformats.org/discuss/mail/microformats-dev/2008-June/000552.html uf-dev archive, 20/06/08, "Using class for non-human data"]) has proposed as an alternative to the empty span and title solution to use the class name in the following way:
<pre><nowiki>
10 o'clock on the 10th
</nowiki></pre>
Pros:
* Allows data to be represented in a "non-harmful" way. Will not be read aloud by screenreaders or seen as tooltips.
* Minimises mark-up used.
* Arguably more semantic than use of "title" attribute for non-human data.

Cons:
* data in the class attribute has already been discussed numerous times in the mailing list over the years and rejected and documented as an [[anti-pattern]] - captured [http://microformats.org/wiki?title=anti-patterns&diff=24271&oldid=24270 on the wiki this past January 2008].
* Possible misuse of class attribute, although as noted previously, the HTML spec states "for general purpose processing by user agents".
* The class attribute has been adopted by the broader web design community to "subclass" element semantics, and to layer additional semantics. To date, microformats has followed this existing practice developed by modern web designers ("paving the cow-paths"). This use of class for data is outside all current practices.

Discussion:
* This proposal smells icky, but I can't quite put my finger on why. Considered objectively, it does seem to be the least harmful solution proposed so far. [[User:TobyInk|TobyInk]] 06:06, 21 Jun 2008 (PDT)
* I really like it, especially given the HTML4 spec gives this as an IMO perfectly valid use (on both id and class, with the following examples given in the id section: "identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc."). Clean and simple. [[User:Dracos|Dracos]] 03:53, 23 Jun 2008 (PDT)
* I suggest dropping the redundant 'data-' prefix, unless someone can suggest a feasible case with two time-stamps requiring different prefixes. The proposal then becomes [http://www.robertnyman.com/2008/04/28/do-we-really-need-microformats/#comment-263408 one I've made before] [[User:AshSearle|AshSearle]]
** Valid class names cannot begin with a number, so a date needs some sort of letter prefix. It's sensible to make this prefix meaningful and reusable in some way. [[User:Phae|Phae]]
*** They can't in CSS, but they can in (X)HTML. http://examples.tobyinkster.co.uk/numeric-classes.html [[User:TobyInk|TobyInk]] 06:53, 24 Jun 2008 (PDT)
** Not to advocate too strongly for designing for parsers (generally a bad idea), *but* having a 'data-' prefix on a class name would make identifying data orders of magnitude easier for parsing. Otherwise, how do we know what's data and what's just another class name for some other purpose? [[User:DrewMcLellan|Drew]]
** A 'data-' prefix would help authors tasked with maintaining or reviewing a page to understand the purpose of a class name that may have been applied by another author. The data prefix communicates very simply that the class name is precisely that, data. Therefore the value is less likely to be accidentally removed or changed, making for a more robust design. [[User:DrewMcLellan|Drew]]
*** I concede - regardless of whether it's valid (X)HTML / CSS - a prefix is needed to distinguish data values from genuine content. ISO 8601 allows date-time to be as simple as "2004", which could easily be misinterpreted. e.g. if a CMS outputs product model numbers into the class attribute for some other purpose. --[[User:AshSearle|AshSearle]] 01:42, 25 Jun 2008 (PDT)
* -1 [[User:Tantek|Tantek]]. I'm vehemently opposed to putting data in the class attribute. We ''must'' find better alternatives. We must not go down the path of invisible (dark) (meta)data - IMHO that [[principle]] is inviolable for microformats.
** [[User:JakeArchibald|JakeArchibald]] If you're so opposed, it'd be useful to see some justification.
*** See above cons. Already discussed/rejected many times in the history of microformats discussions. In short, quit wasting time on old ground. Abuses class attribute, or if you prefer, introduces a *new* use of the class attribute, unlike microformats to-date which have simply made use of a well established semantic of the class attribute. And worst of all, completely violates the visible data [[principle]]. Rejectable on that alone.
**** The fact that something has been discussed and rejected before is not sufficient grounds for dismissing it out of hand once additional research and thinking has taken place. The <abbr> datetime pattern arguably abused the title attribute and introduced a new use of the title attribute. In the example given (<code><nowiki>10 o'clock on the 10th</nowiki></code>), the data is presented as "10 o'clock on the 10th" - very visible. Yes, of course, it's possible to abuse this proposed pattern, and hide the data, but the same can be said of the abbr pattern or even the class pattern given CSS's display:none property. Experience shows that in most cases, people ''won't'' abuse the pattern to hide data, as they actually ''want'' to show the data on their pages. [[User:TobyInk|TobyInk]] 13:52, 24 Jun 2008 (PDT)
**** It's not an abuse of the class attribute according to the HTML spec. as I read it. Whereas using title for non-human data is (the spec says audio agents may read it aloud, for example). If it's a new use, it's one the writers of HTML4 considered, so it wasn't new to them. [[User:Dracos|Dracos]] 03:38, 25 Jun 2008 (PDT)
** Relevant princeples are 'humans first, machines second', and 'visible data is ''better'''. These are ''preferences'', not inviolable principles. Besides, the existing datetime spec doesn't adhere to these principles anyway: prioritising humans first, <code><nowiki>let's discuss this at the next meeting</nowiki></code> should be marked up as <code><nowiki>let's discuss this at the <abbr title="28th June 2008 at 3:15pm">next meeting</nowiki></code>. There's a conflict between human- and machine-readable dates. It makes more sense to 'hide' the machine-readable data in the only attribute available to us: <code>class</code>. --[[User:AshSearle|AshSearle]] 03:02, 25 Jun 2008 (PDT)
*** Indeed - by their nature, ''principles'' are ''generalisations'', and while broadly useful, usually have exceptions. After experience, the microformats community is beginning to see some of these. Human vs machine dates is the one gathering the most interest at the moment, largely thanks to <abbr class="help" style="border-bottom:1px dotted" title="the Web Standards Project">WaSP</abbr> and auntie, but I think other properties which will probably emerge as exceptions to the general microformats principles are hReview's <code>type</code> property, and the its namesake subproperty for hCard's <code>tel</code>, <code>email</code> and <code>adr</code> (and <code>label</code>?) properties. [[User:TobyInk|TobyInk]] 12:51, 25 Jun 2008 (PDT)

==== Experimental Parser Support ====

[http://buzzword.org.uk/cognition/ Cognition 0.1 alpha 10] will include experimental support for this pattern, and the [http://srv.buzzword.org.uk Cognition web service] already does. Notes:
* Support is ''opt-in''. Publishers must explicitly request support for the pattern, by including a [[profile-uris|profile URI]] of <code><nowiki>http://purl.org/uF/pattern-data-class/1</nowiki></code> in their document head.
* Support is not limited to date-time properties, but any microformat properties.
* data-X classes must use percent-encoding to encode spaces and other characters not allowed in class names.
* The data-X class must be found on the same element as the microformat property class. That is, you cannot use: <pre><nowiki>10 o'clock</nowiki></pre>
<ul><li>Multiple data-X classes may occur on the same element. When these are found, the longest string is used. This allows for: <pre><nowiki>The 10th</nowiki></pre> which may be useful for styling or other non-microformat purposes.</li>
<li>Can be combined with value excerpting. e.g. <pre><nowiki>

The concert will be held on
the 4th of August
starting at
7:30pm precisely.

</nowiki></pre></li></ul>

=== date and time separation using value excerption ===

==== summary ====
By specifying a more precise parsing of the use of "value" excerption inside all datetime properties (e.g. dtstart, dtend, published, updated etc.), dates and times can be marked up separately, thus reducing/minimizing (and potentially eliminating) the readability issues that come with compound ISO8601 datetimes.

==== introductory example ====
The sentence:

<pre><nowiki>
The weekly dinner is tonight at 6:30pm.
</nowiki></pre>

would be marked up as:

<pre><nowiki>
The weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
at <abbr class="value" title="18:30">6:30pm</abbr>.
</nowiki></pre>

==== advantages ====
* re-uses the readable [[abbr-date-pattern]]
* identifies a similarly readable abbr-time-pattern.
* minimizes DRY violation distance, keeps machine data on exactly the same element as the respective human data
** even better than [[abbr-datetime-pattern]] does, which, in practice from experience often required specifying the date in machine readable form on the human readable time (separate from the human readable date).
* introduces no new class names - [[principle]] of minimal invention
* introduces no new use of the class attribute - principle of minimal invention again
* introduces no new syntax ([[datetime-design-pattern#problems_with_strtime_proposal|see above]] about any publishing method that requires the author to think like a programmer being a non-starter, and introducing new syntax almost always requires authors to think like programmers).
* and most importantly, introduces no dark data.

==== issues ====
Some potential issues were raised in IRC, and it helps to document/resolve them so that they are not brought up repeatedly.
* [[http://rbach.priv.at/Microformats/IRC/2008-06-24#T163114 Does this sufficiently address the concerns raised with the current use of abbr-pattern?]]
*# The [[abbr-date-pattern]], as documented and explained by [[User:Adactio|Jeremy Keith]] is just fine (in contrast to the [[abbr-datetime-pattern]]).
*# Similar to the [[abbr-date-pattern]], this proposal implies/introduces the abbr-time-pattern, which is similarly acceptable.
** That's not a complete coverage of the ABBR complaints. Separating into 2008-06-07 and 18:03 improves the ability for humans to consume the data, but still exposes data through tooltips and speech in formats that the publisher did not choose to use. --[[User:BenWard|BenWard]] 04:52, 25 Jun 2008 (PDT)
*** if a site publisher wishes to customize the presentation of tooltips, they can do so with a nested span with title.
**** That proposes extraneous mark-up maintain the publisher's wish not to have a tool-tip in the first place. I object to a microformat pattern requiring an immediate work-around to meet publisher's desires. It goes against ‘Humans first…’. --[[User:BenWard|BenWard]] 09:09, 30 Jun 2008 (PDT)
** Additionally, it does not solve the semantic misuses of ABBR. That ‘tonight’ is ever a textual, human abbreviation of ‘2008-06-24’ is not accepted, nor is it possible to use this mark-up and always maintain proper sentences with the expanded form. e.g. <code>it's my <abbr class="bday" title="2005-06-20">birthday today</abbr>!</code> becomes ‘it's my 2005-06-20!’. That content remains broken by the continued stretch of ABBR semantics. --[[User:BenWard|BenWard]] 04:52, 25 Jun 2008 (PDT)
*** I concur. We need to explore a solution that allows authors to choose what mark-up they use to best fit their implementation. Publishing practices and desires show us that authors are not willing to compromise the semantics of abbr. [[User:Phae|Phae]] 04:30, 27 Jun 2008 (PDT)
* [[http://rbach.priv.at/Microformats/IRC/2008-06-24#T163435 That's getting pretty complicated]]
** Much less complicated than inventing yet another syntax ( " { ... } " ???? ) that web authors would have to learn.
*** But it's all in one place, rather than spreading it out.
**** The spreading it out is what current content publishing practices do already! It is much more important to map the machine data as close to the existing publishing practice as possible, than to try to "put it all in one place". The "put it all in one place" way of thinking is why people ended up sticking so much invisible metadata in the head of the document, which we know fails.
* Audio rendition of such titles can be nonsensical - "The weekly dinner is two thousand and eight dash zero six dash twenty four at eighteen thirty."

==== content requirements ====
Some requirements which enhance both human readability, ''and'' machine parsability (best of both) :
* date value excerpts MUST use hyphen separators. E.g. 2008-06-24. Not ok:20080624.
* time value excerpts MUST use colon separators (seconds optional, implied :00 if absent). E.g. 18:30 or 18:30:00. Not ok:183000.
* timezone value excerpts MUST use leading plus or minus and NO colon separator. E.g. -0700. Not ok:-07:00.

==== derivation ====
It's important to document the derivation/background of a brainstorm/proposal as it allows others to see some of the thinking that went into it, and avoid having to rediscuss alternatives already considered, and helps provide understanding as to why aspects of the design are as they are.
===== example with datetime =====
Here is a short code example:
<pre><nowiki>
the weekly dinner is tonight at 2008-06-24T18:30
</nowiki></pre>
===== example with abbr datetime =====
However that's not the easiest to read, nor do most people publish that as human visible text, so per the abbr-datetime pattern:
<pre><nowiki>
the weekly dinner is tonight at <abbr class="dtstart" title="2008-06-24T18:30">6:30pm</abbr>
</nowiki></pre>

which has raised two issues:
# When "2008-06-24T18:30" is inspected by a human reading a tooltip, or spoken by a screen reader, it's not the most understandable thing (precise citation needed, perhaps an mp3 with screen reader used version info).
# There is a non-local violation of DRY (which IMHO is a worse problem, as it leads to worse data quality -[[User:Tantek|Tantek]]). That is, the "date" information is now not only in the text twice (as it was before), but those two instances of the date information are not on the same element, which makes it worse. That is, "tonight" is in the prose, ''outside'' of the element with the precise date "2008-06-24".

In analysis of examples of event information on the web, the date and time are often published in separate elements, often for display purposes.

Thus it is this existing content publishing practice which leads to this brainstorm proposal, to essentially to introduce a date and time value excerption longhand.

(Initially [http://rbach.priv.at/Microformats/IRC/2008-06-21#T181634 Tantek's idea that he bounced off Jeremy Keith] ([http://rbach.priv.at/Microformats/IRC/2008-06-24#T124652 similar idea conceived by Drew independently]) was to [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161819 introduce new classes "datevalue", "timevalue"] and "tzvalue" for this purpose, but [http://rbach.priv.at/Microformats/IRC/2008-06-24#T171603 Bob Jonkman pointed out] that HTML5's time parsing algorithm enables a single <nowiki><time></nowiki> element to contain dates or times (with or without timezone) without having to explicitly say whether the value contains dates or times (with or without timezone). [http://rbach.priv.at/Microformats/IRC/2008-06-24#T171723 Bob then proposed] that thus all was needed was a single new "datetime" class name. This was the key realization that allowed minimal invention. Tantek pointed out that since from the type of property we already know it is a datetime, [http://rbach.priv.at/Microformats/IRC/2008-06-24#T171835 there was no need for even one new class name], that we could simply re-use "value" excerption, and simply more precisely specify the semantics/parsing in the case of datetime properties.)

===== example with new date and time value excerpts =====
Thus we markup the date and time separately, as value excerpts, using the [[abbr-date-pattern]] and an implied parallel abbr-time-pattern:

<pre><nowiki>
The weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
at <abbr class="value" title="18:30">6:30pm</abbr>.
</nowiki></pre>

===== separate subtrees =====
The proposal also allows setting the date and time in separate element subtrees as well, which may be necessary for some document structures:

<pre><nowiki>
the weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
at <abbr class="value" title="18:30">6:30pm</abbr>.
</nowiki></pre>

Note the two instances of dtstart, one of which sets the date for the dtstart, and the other of which sets the time.

The idea being, when a parser sees a datetime property (e.g. dtstart) with a value excerpt, that it only "set" the component of its full value that is specified by the value excerpt (e.g. the date), and that if lacking a complete datetime, it continue to parse additional instances of that datetime property for the remaining component(s) (e.g. the time).

Of course this only works for singular properties, but fortunately all instances of datetime properties so far are singular, so this works.

===== reusing date data for multiple datetime properties =====
This also provides a *very* convenient way to re-use the same date information for start and end, e.g. expanding the example:

<pre><nowiki>
the weekly dinner is <abbr class="value" title="2008-06-24">tonight</abbr>
from <abbr class="value" title="18:30">6:30</abbr> -
<abbr class="value" title="20:30">8:30pm</abbr>.
</nowiki></pre>

Note what just happened. we just eliminated another duplication of date information by reusing the start *date* information for the end *date* information and *only* specifying the end *time* information separately for the two properties.

Reducing the duplication (or triplication) of such data helps to reduce the chances of (even inadvertent) data corruption/drift/divergence among any duplicates.

===== time zones =====
There are a few choices for timezones.
# Simply include the time zone information as part of the time "value". E.g. <code><nowiki><abbr class="value" title="18:30-0700">6:30pm</abbr></nowiki></code>
# Or use another value excerpt for the timezone (was: <del>introduce the class name "tzvalue"</del>) E.g. <code><nowiki><abbr class="value" title="18:30">6:30pm</abbr> <abbr class="value" title="-0700">PDT</abbr></nowiki></code>
# Or allow both and let web authors decide. This is the current leaning.
#* if web authors want to specify timezone as part of the time (first example above), they can,
#* or if web authors visibly publish the timezone separately (second example above), then they can mark that up.
#* or if web authors wish to omit timezone information, they can do so as well, as most do today. In practice this works fine, as it creates a "floating" time which works fine in far more than the 80/20.

(more to come, documenting [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161740 from IRC logs])

==== discussion ====
Opening up a discussion section even though documentation [http://rbach.priv.at/Microformats/IRC/2008-06-24#T161740 from IRC logs] is still in progress. :)

* regarding the [[datetime-design-pattern#advantages|advantage]] of "and most importantly, introduces no dark data."
** "Dark data" is sometimes what publishers *want* to publish. To use the example of TV schedules which kick started the renewed discussion in this area, publishers will often not want to display the date. For instance, if a page entitled "Tomorrow's TV" and containing 300 different programmes marked up with <code>dtstart</code>, it is superfluous to explicitly display the date for each one. With this proposed solution the [[include|include pattern]] could be used to include the date into each vevent, but a visible link to the date on each programme would simply be confusing. Sometimes it just makes sense to hide some of the information you're publishing as a microformat - because the information you want to make explicit to parsers can be inferred from context by humans, or is more appropriately displayed at a different level of granularity for machines and humans. [[User:TobyInk|TobyInk]] 14:26, 24 Jun 2008 (PDT)
*** It doesn't matter whether publishers *want* to publish dark data or not. Invisible data always leads to poorer quality data. Publishers publish all kinds of invisible metadata in the heads of documents etc. because they want to, but their desire doesn't stop the data from becoming obsolete, diverging from the actual visible data etc. The quality of the data matters more than any publishers wish(es) of publishing in a specific format, or in a hidden way. In the example you gave, using the include pattern in that way would not result in any visible links, but merely empty include anchors. It never makes any sense to actually hide "some of the information you're publishing as a microformat", because historically that always results in some loss of data quality over time and thus the microformats [[principle]] of visible data instead of invisible metadata. [[User:Tantek|Tantek]] 14:32, 24 Jun 2008 (PDT)
**** All microformats hide ''some'' data. In the example <code><nowiki>01632 960123</nowiki></code>, the information that the long string of numbers represents a telephone number is invisible. And making it visible (<code><nowiki>Tel: 01632 960123</nowiki></code>) violates DRY. It's just a matter of where to draw the line.
***** That statement makes the mistake of conflating *type* data and *content* data. "tel" is not content data, just as <nowiki></nowiki> is not content data. It's markup, indicating the type of the data. Markup (type data) being invisible to the user has worked just fine. Content (content data) being invisible to the user is the problem of dark data. Or rather, if you think that everything is data, then you really should be spending time developing in a system that is built on that assumption, e.g. RDF, rather than microformats, which are built on HTML, and the clear separation of type of data (HTML elements, microformats properties) and content data (inner text, text attribute values).
****** My point is that there isn't a ''distinction'' between the two, but a ''continuum''. The choice of where to draw the line is never a clear one and always somewhat arbitrary. The vCard standard could quite easily have ended up with separate "TEL", "FAX" and "CELL" properties, in which case hCard would have ended up with <code><nowiki><foo class="tel"></nowiki></code>, <code><nowiki><bar class="fax"></nowiki></code> and <code><nowiki><baz class="cell"></nowiki></code>. Going the other way, they could have stored e-mail addresses as mailto: URLs, and then hCard would have <code><nowiki><a class="url" href="mailto:quux@example.com"></nowiki></code>. They chose the way they did, and as a result in hCard the distinction between a mailto: URI and an http: URI is largely invisible (in most circumstances only obvious by looking at the status bar when hovering), but the distinction between a telephone number and a fax number is visible. But that wasn't the only possible (nor the only reasonable) outcome.

=== HTML 5 <code><time></code> Element ===

[http://microformats.org/wiki/hcalendar-issues#html5-time-element See hCalendar issues]

=== Plain Old English alternative to ISO date ===

Example (in English):

<pre>
<abbr title="January 25th, 2008" class="dstart" lang="en-us">1/25</abbr>
</pre>

<pre>
January 25th, 2008
</pre>

If <code>lang="en-us"</code>, the format of the date used in the <code>title</code> attribute must conform to [http://www.ego4u.com/en/cram-up/vocabulary/date/written dates writing rules in American English].

Example (in French):

<pre>
<abbr title="25 Janvier 2008" class="dstart" lang="fr">25/1</abbr>
</pre>

If <code>lang="fr"</code>, the format of the date used in the <code>title</code> attribute must conform to date writing rules in French.

====Benefits====

* Human-hearable: should work nicely with screen readers (to be tested).
* Human-readable
* Compliance with semantics of abbr.
* Very easy to used by HTML human authors.
* DRY compliant if HTML human authors are willing to write in correct English

====Drawbacks====

* Locale-specific parsing logic.

====Notes====

* Could work alongside with the existing [[datetime-design-pattern]]: if ISO date parsing fails, try parsing the title as a human-readable plain old English/French/... date according to the locale.

== See Also ==

* [[Main_Page#Design_Patterns|All microformat design patterns]]
* [[abbr-design-pattern]] is used by [[datetime-design-pattern]]
* [[date-design-pattern]] is a subset of [[datetime-design-pattern]]
* HTML 4.01 definition of <code><[http://www.w3.org/TR/REC-html40/struct/text.html#edef-ABBR abbr]></code> element
* RFC [http://www.faqs.org/rfcs/rfc3339.html 3339]: Date and Time on the Internet: Timestamps
* W3C: [http://www.w3.org/TR/NOTE-datetime Note on Datetimes]
* Markus Kuhn: [http://www.cl.cam.ac.uk/~mgk25/iso-time.html A summary of the international standard date and time notation]
* Wikipedia: [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]

include-pattern-brainstorming

2008-02-12T00:30:07Z

Guillaume Lebleu: /* contributors */

<h1>include pattern brainstorming</h1>
{{TOC-right}}

brainstorming to improve or extend the [[include-pattern]].

== alternatives to using a or object ==
Here are possible variations on the [[include-pattern|include pattern]], attempting to resolve issues of accessibility (with empty anchors) and server load (with <code>object</code>).

=== Non-Verbose Class-Based Solution ===
(Originally suggested by Toby Inkster, based on an earlier proposal by Andy Mabbett)

An alternative way of implementing the include pattern in a less verbose, and hopefully more accessible manner.

<pre>
We have three branches in London,
including our head office in Kensington:
<ul>
<li class="adr #ldn">
123 Oxford Street
</li>
<li class="adr #ken #ldn">
5 Kensington High Street
</li>
<li class="adr #ldn">
1 Pall Mall
</li>
</ul>
</pre>

The order of the space-delimited class attributes should be considered significant -- that is, in <foo class="bar #baz"> the content referred to by #baz is logically included as the last child of the <foo> element, but in <foo class="#baz bar">, it is logically included as the first child. (See below for an example where the included element should occur in the middle of the element content.)

Yes, the hash mark is valid in the class attribute, though rarely used because it won't work with CSS 1 selectors.

If people can find real-life uses of the hash character in existing sites that would conflict with this proposed usage pattern, then perhaps another character could be used. I rather like '@foo', or maybe even a combination such as '@#foo'.

==== Including data in the middle of an element ====

Above, the examples show how an element can be logically included as the first or last child of another element. For including data into the middle of an element, we need to be a tiny bit more verbose and insert a dummy element (in this case a element) where the included content should go:

<pre>
Our head office is in London at:

5 Kensington High Street 

SW7 1AA

</pre>

==== problems with ordered ids in class ====
Two problems:

1. class is an unordered set of values per HTML4. introducing ordering is a non-starter both from a violation of HTML4 spec perspective and likely requiring of rewriting HTML4 parsers to maintain an ordering where they currently don't.

<div style="margin-left:2em;border-left:thick solid #ccc;padding-left:1em;">
A reading of HTML 4.01, section 7.5.2 doesn't seem to claim that the class list is unordered.

It does claim that it's a "set" of class names, and in mathematical parlance sets are unordered by definition, and must not contain duplicates, but it's unlikely that the framers of the HTML 4.01 spec intended the world "set" to be interpreted in that way -- far more likely they were referring to the layman's definition of the word.

As far as parsers are concerned, DOM Level 2 HTML provides as "className" property as part of the HTMLElement interface, which is either directly used or is inherited by all DOM element nodes. The className is a string exactly reflecting the contents of the HTML class attribute, so should reflect their original order.

And any non-DOM, naive SGML or XML parser that encounters a class attribute will just parse it as a plain old string anyway, so the order should be retained.

[[User:TobyInk|TobyInk]] 08:34, 5 Feb 2008 (PST)
</div>

2. inclusion of arbitrary data (#baz) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]]. [[User:Tantek|Tantek]]

<div style="margin-left:2em;border-left:thick solid #ccc;padding-left:1em;">
This anti-pattern is only mentioned as a subheading to the more general anti-pattern of invisble metadata. My suggested pattern for inclusions does not hide metadata -- it merely references metadata elsewhere on the page. It is no more guilty of hiding metadata than any other suggested include pattern, so I fail to see how this is relevant.

[[User:TobyInk|TobyInk]] 08:36, 5 Feb 2008 (PST)
</div>

===Simple class name===

:<code><foo id="birmingham" class="locality">Birmingham</foo></code>

then:

:<code><foo class="adr includes-birmingham">[...]</foo></code>

Some other possible variants are:

:<code><foo class="adr birmingham">[...]</foo></code>

or

:<code><foo class="adr part-microformat birmingham">[...]</foo></code>

or

:<code><foo class="adr use-birmingham">[...]</foo></code>

or

:<code><foo class="adr uses-birmingham">[...]</foo></code>

or

:<code><foo class="adr include-birmingham">[...]</foo></code>

or

:<code><foo class="adr locality-birmingham">[...]</foo></code>

or

:<code><foo id="birmingham">Birmingham</foo></code>

:[...]

:<code><foo class="adr locality-birmingham">[...]</foo></code>

(originally suggested by [[User:AndyMabbett|Andy Mabbett]] in <http://microformats.org/discuss/mail/microformats-discuss/2008-January/011422.html et seq.)

==== problems with arbitrary id values in class attributes ====
In short: similar to [[#problems_with_ordered_ids_in_class|problems with ordered ids in class]], inclusion of arbitrary data (birmingham) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].

Longer: The value of an <code>id</code> attribute on an element is essentially an arbitrary string used to uniquely identify that element in the context of the document. Thus the re-use of such an arbitrary string (e.g. "birmingham") in a class attribute is an instance of including arbitrary data in the class attribute, which is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].

[[User:Tantek|Tantek]]

* In this proposal, the class name is not "arbitrary data", since it uses a semantically valid IDs; and is semantically logical. In the cited page the use of data in class names is deprecated as "another form of invisible metadata". This proposal involves no more "invisible metadata" than do the existing include patterns. [[User:AndyMabbett|Andy Mabbett]] 00:52, 4 Feb 2008 (PST)
** existing include patterns use <code>href</code> and <code>data</code> (not <code>class</code>) attributes which are both of type URI to point to a fragment identifier. arbitrary links are proper semantic use of URI attributes per HTML4. however in a class attribute, arbitrary links are no more than arbitrary data, and are thus an example of [[anti-patterns#data_in_class_attributes|the documented anti-pattern]]. (Unsigned comment by [[User:Tantek|Tantek]])
*** The fragment identifier is not data. Well, OK, it is data in the sense that virtually everything is data, but, in the example above, the link itself is not address data -- it's a pointer to data... information about where the real data might be found... it's ''metadata''. [[User:TobyInk|TobyInk]] 07:42, 6 Feb 2008 (PST)

===Use <code>@</code> to Reference IDs===

Don't <code>"include"</code> your data, you could perhaps just reference them.

<pre><foo id="me" class="fn">Fred</foo></pre>

<pre><bar class="me@url">http://wherever.com/</bar></pre>

parsers instead of replacing data can then just append their data?

Suggested in: [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011470.html microformats-discuss/2008-February/011470.html]

==== problems with using at ref to id ====
* Too verbose http://microformats.org/discuss/mail/microformats-discuss/2008-February/011473.html
* Inclusion of arbitrary data <code>@</code>, "[[anti-patterns#data_in_class_attributes|documented anti-pattern]]" as pointed out on microformats discuss http://microformats.org/discuss/mail/microformats-discuss/2008-February/011479.html

===Use a Class Create method===

Create a class such as <code>"data"</code> in the following example, or any unique class name much the same as we do already with <code>id=""</code>.

Examples could be <code>"reviewer"</code> or <code>"me"</code>.

example,
<pre>

Foo

<a class="email" href="mailto:foo@bar.com">email foo@bar.com</a>
</pre>

Use an empty span to reference your unique class name with class <code>"include *"</code> anywhere you would
like the created class to be included.

example,
<pre>

<a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
</pre>

The result "could" turn out much like this:

example,
<pre>
Foo
<a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
</pre>

====Problems====

* If class="include data" is taken to mean "include all elements with a class name of 'data'", then the element will include itself and potentially introduce problems with recursion. [[User:TobyInk|TobyInk]] 02:23, 11 Feb 2008 (PST)
** Not Necessarily so, It would depend on Parsing rules. [[User:WebOrganics|Martin McEvoy]] 17:19, 11 Feb 2008 (GMT)

=== Use property inheritance from groups, implicit member/group relations (by containment) and explicit property/object relations (by reference) ===

This proposal is only presented for the record. The main reason it has been discarded is because "the use of [[rev]], and any new microformats values for rev, has been deprecated for several reasons. See [[rev#Should_rev_even_be_used|Should rev even be used]].".

It is really two proposals in one:
* property inheritance from group elements: if an object is part of a group, it inherits the properties associated with this group.
* explicit property referencing. This technique provides an alternative to the current technique of associating by containment a property with an object, or sub-property with parent property. With the suggested new technique, the property or sub-property does not have to be contained (resp.) by the object or parent property: the association is made explicitly via a rev link.

Example:

<pre>
Our company has office locations in <a href="#adrlist1" rev="locality">San Francisco</a>:
<ul id="adrlist1">
<li id="adr1" class="adr">665 3rd Street, and</li>
<li id="adr2" class="adr">123 Folsom</li>
</ul>
</pre>

This example would be interpreted as:
* adr1 and adr2 belong to the group adrlist1 by containment.
* "San Francisco" is the locality property of the adrlist1 group.
* hence, adr1 and adr2 inherit the locality property from adrlist1 since they are not overriding it.

=== Use property inheritance from groups, explicit group/member referencing and implicit property relations (by containment) ===

<pre>
Our company has office locations in San Francisco:
<a id="adr1" href="#adrlist1" rel="group" class="adr">665 3rd Street,
and <a id="adr2" href="#adrlist1" rel="group" class="adr">123 Folsom
</pre>

This technique use: property inheritance from group and explicit relationships between groups and members. The HTML code actual reflects the meaning of the sentence: the items following the columns belong to a group from which they inherit a property (locality).

This example would be interpreted as:
* adr1 and adr2 belong to the #adrlist1 group (by reference).
* locality is associated with #adrlist1 by containment
* adr1 and adr2 inherit the locality property "San Francisco" from the group they belong to, since they are not overriding it.

== contributors ==
* [[User:TobyInk|Toby Inkster]]
* [[User:AndyMabbett|Andy Mabbett]]
* [[User:WebOrganics|Martin McEvoy]]
* [[User:Guillaume Lebleu|Guillaume Lebleu]]

== Related Pages ==
{{include-pattern-related-pages}}

include-pattern-brainstorming

2008-02-12T00:29:32Z

Guillaume Lebleu: /* Use property inheritance from groups, explicit group/member referencing and implicit property relations (by containment) */

<h1>include pattern brainstorming</h1>
{{TOC-right}}

brainstorming to improve or extend the [[include-pattern]].

== alternatives to using a or object ==
Here are possible variations on the [[include-pattern|include pattern]], attempting to resolve issues of accessibility (with empty anchors) and server load (with <code>object</code>).

=== Non-Verbose Class-Based Solution ===
(Originally suggested by Toby Inkster, based on an earlier proposal by Andy Mabbett)

An alternative way of implementing the include pattern in a less verbose, and hopefully more accessible manner.

<pre>
We have three branches in London,
including our head office in Kensington:
<ul>
<li class="adr #ldn">
123 Oxford Street
</li>
<li class="adr #ken #ldn">
5 Kensington High Street
</li>
<li class="adr #ldn">
1 Pall Mall
</li>
</ul>
</pre>

The order of the space-delimited class attributes should be considered significant -- that is, in <foo class="bar #baz"> the content referred to by #baz is logically included as the last child of the <foo> element, but in <foo class="#baz bar">, it is logically included as the first child. (See below for an example where the included element should occur in the middle of the element content.)

Yes, the hash mark is valid in the class attribute, though rarely used because it won't work with CSS 1 selectors.

If people can find real-life uses of the hash character in existing sites that would conflict with this proposed usage pattern, then perhaps another character could be used. I rather like '@foo', or maybe even a combination such as '@#foo'.

==== Including data in the middle of an element ====

Above, the examples show how an element can be logically included as the first or last child of another element. For including data into the middle of an element, we need to be a tiny bit more verbose and insert a dummy element (in this case a element) where the included content should go:

<pre>
Our head office is in London at:

5 Kensington High Street 

SW7 1AA

</pre>

==== problems with ordered ids in class ====
Two problems:

1. class is an unordered set of values per HTML4. introducing ordering is a non-starter both from a violation of HTML4 spec perspective and likely requiring of rewriting HTML4 parsers to maintain an ordering where they currently don't.

<div style="margin-left:2em;border-left:thick solid #ccc;padding-left:1em;">
A reading of HTML 4.01, section 7.5.2 doesn't seem to claim that the class list is unordered.

It does claim that it's a "set" of class names, and in mathematical parlance sets are unordered by definition, and must not contain duplicates, but it's unlikely that the framers of the HTML 4.01 spec intended the world "set" to be interpreted in that way -- far more likely they were referring to the layman's definition of the word.

As far as parsers are concerned, DOM Level 2 HTML provides as "className" property as part of the HTMLElement interface, which is either directly used or is inherited by all DOM element nodes. The className is a string exactly reflecting the contents of the HTML class attribute, so should reflect their original order.

And any non-DOM, naive SGML or XML parser that encounters a class attribute will just parse it as a plain old string anyway, so the order should be retained.

[[User:TobyInk|TobyInk]] 08:34, 5 Feb 2008 (PST)
</div>

2. inclusion of arbitrary data (#baz) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]]. [[User:Tantek|Tantek]]

<div style="margin-left:2em;border-left:thick solid #ccc;padding-left:1em;">
This anti-pattern is only mentioned as a subheading to the more general anti-pattern of invisble metadata. My suggested pattern for inclusions does not hide metadata -- it merely references metadata elsewhere on the page. It is no more guilty of hiding metadata than any other suggested include pattern, so I fail to see how this is relevant.

[[User:TobyInk|TobyInk]] 08:36, 5 Feb 2008 (PST)
</div>

===Simple class name===

:<code><foo id="birmingham" class="locality">Birmingham</foo></code>

then:

:<code><foo class="adr includes-birmingham">[...]</foo></code>

Some other possible variants are:

:<code><foo class="adr birmingham">[...]</foo></code>

or

:<code><foo class="adr part-microformat birmingham">[...]</foo></code>

or

:<code><foo class="adr use-birmingham">[...]</foo></code>

or

:<code><foo class="adr uses-birmingham">[...]</foo></code>

or

:<code><foo class="adr include-birmingham">[...]</foo></code>

or

:<code><foo class="adr locality-birmingham">[...]</foo></code>

or

:<code><foo id="birmingham">Birmingham</foo></code>

:[...]

:<code><foo class="adr locality-birmingham">[...]</foo></code>

(originally suggested by [[User:AndyMabbett|Andy Mabbett]] in <http://microformats.org/discuss/mail/microformats-discuss/2008-January/011422.html et seq.)

==== problems with arbitrary id values in class attributes ====
In short: similar to [[#problems_with_ordered_ids_in_class|problems with ordered ids in class]], inclusion of arbitrary data (birmingham) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].

Longer: The value of an <code>id</code> attribute on an element is essentially an arbitrary string used to uniquely identify that element in the context of the document. Thus the re-use of such an arbitrary string (e.g. "birmingham") in a class attribute is an instance of including arbitrary data in the class attribute, which is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].

[[User:Tantek|Tantek]]

* In this proposal, the class name is not "arbitrary data", since it uses a semantically valid IDs; and is semantically logical. In the cited page the use of data in class names is deprecated as "another form of invisible metadata". This proposal involves no more "invisible metadata" than do the existing include patterns. [[User:AndyMabbett|Andy Mabbett]] 00:52, 4 Feb 2008 (PST)
** existing include patterns use <code>href</code> and <code>data</code> (not <code>class</code>) attributes which are both of type URI to point to a fragment identifier. arbitrary links are proper semantic use of URI attributes per HTML4. however in a class attribute, arbitrary links are no more than arbitrary data, and are thus an example of [[anti-patterns#data_in_class_attributes|the documented anti-pattern]]. (Unsigned comment by [[User:Tantek|Tantek]])
*** The fragment identifier is not data. Well, OK, it is data in the sense that virtually everything is data, but, in the example above, the link itself is not address data -- it's a pointer to data... information about where the real data might be found... it's ''metadata''. [[User:TobyInk|TobyInk]] 07:42, 6 Feb 2008 (PST)

===Use <code>@</code> to Reference IDs===

Don't <code>"include"</code> your data, you could perhaps just reference them.

<pre><foo id="me" class="fn">Fred</foo></pre>

<pre><bar class="me@url">http://wherever.com/</bar></pre>

parsers instead of replacing data can then just append their data?

Suggested in: [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011470.html microformats-discuss/2008-February/011470.html]

==== problems with using at ref to id ====
* Too verbose http://microformats.org/discuss/mail/microformats-discuss/2008-February/011473.html
* Inclusion of arbitrary data <code>@</code>, "[[anti-patterns#data_in_class_attributes|documented anti-pattern]]" as pointed out on microformats discuss http://microformats.org/discuss/mail/microformats-discuss/2008-February/011479.html

===Use a Class Create method===

Create a class such as <code>"data"</code> in the following example, or any unique class name much the same as we do already with <code>id=""</code>.

Examples could be <code>"reviewer"</code> or <code>"me"</code>.

example,
<pre>

Foo

<a class="email" href="mailto:foo@bar.com">email foo@bar.com</a>
</pre>

Use an empty span to reference your unique class name with class <code>"include *"</code> anywhere you would
like the created class to be included.

example,
<pre>

<a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
</pre>

The result "could" turn out much like this:

example,
<pre>
Foo
<a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
</pre>

====Problems====

* If class="include data" is taken to mean "include all elements with a class name of 'data'", then the element will include itself and potentially introduce problems with recursion. [[User:TobyInk|TobyInk]] 02:23, 11 Feb 2008 (PST)
** Not Necessarily so, It would depend on Parsing rules. [[User:WebOrganics|Martin McEvoy]] 17:19, 11 Feb 2008 (GMT)

=== Use property inheritance from groups, implicit member/group relations (by containment) and explicit property/object relations (by reference) ===

This proposal is only presented for the record. The main reason it has been discarded is because "the use of [[rev]], and any new microformats values for rev, has been deprecated for several reasons. See [[rev#Should_rev_even_be_used|Should rev even be used]].".

It is really two proposals in one:
* property inheritance from group elements: if an object is part of a group, it inherits the properties associated with this group.
* explicit property referencing. This technique provides an alternative to the current technique of associating by containment a property with an object, or sub-property with parent property. With the suggested new technique, the property or sub-property does not have to be contained (resp.) by the object or parent property: the association is made explicitly via a rev link.

Example:

<pre>
Our company has office locations in <a href="#adrlist1" rev="locality">San Francisco</a>:
<ul id="adrlist1">
<li id="adr1" class="adr">665 3rd Street, and</li>
<li id="adr2" class="adr">123 Folsom</li>
</ul>
</pre>

This example would be interpreted as:
* adr1 and adr2 belong to the group adrlist1 by containment.
* "San Francisco" is the locality property of the adrlist1 group.
* hence, adr1 and adr2 inherit the locality property from adrlist1 since they are not overriding it.

=== Use property inheritance from groups, explicit group/member referencing and implicit property relations (by containment) ===

<pre>
Our company has office locations in San Francisco:
<a id="adr1" href="#adrlist1" rel="group" class="adr">665 3rd Street,
and <a id="adr2" href="#adrlist1" rel="group" class="adr">123 Folsom
</pre>

This technique use: property inheritance from group and explicit relationships between groups and members. The HTML code actual reflects the meaning of the sentence: the items following the columns belong to a group from which they inherit a property (locality).

This example would be interpreted as:
* adr1 and adr2 belong to the #adrlist1 group (by reference).
* locality is associated with #adrlist1 by containment
* adr1 and adr2 inherit the locality property "San Francisco" from the group they belong to, since they are not overriding it.

== contributors ==
* [[User:TobyInk|Toby Inkster]]
* [[User:AndyMabbett|Andy Mabbett]]
* [[User:WebOrganics|Martin McEvoy]]

== Related Pages ==
{{include-pattern-related-pages}}

include-pattern-brainstorming

2008-02-12T00:28:45Z

Guillaume Lebleu: Added two alternatives to include-pattern

<h1>include pattern brainstorming</h1>
{{TOC-right}}

brainstorming to improve or extend the [[include-pattern]].

== alternatives to using a or object ==
Here are possible variations on the [[include-pattern|include pattern]], attempting to resolve issues of accessibility (with empty anchors) and server load (with <code>object</code>).

=== Non-Verbose Class-Based Solution ===
(Originally suggested by Toby Inkster, based on an earlier proposal by Andy Mabbett)

An alternative way of implementing the include pattern in a less verbose, and hopefully more accessible manner.

<pre>
We have three branches in London,
including our head office in Kensington:
<ul>
<li class="adr #ldn">
123 Oxford Street
</li>
<li class="adr #ken #ldn">
5 Kensington High Street
</li>
<li class="adr #ldn">
1 Pall Mall
</li>
</ul>
</pre>

The order of the space-delimited class attributes should be considered significant -- that is, in <foo class="bar #baz"> the content referred to by #baz is logically included as the last child of the <foo> element, but in <foo class="#baz bar">, it is logically included as the first child. (See below for an example where the included element should occur in the middle of the element content.)

Yes, the hash mark is valid in the class attribute, though rarely used because it won't work with CSS 1 selectors.

If people can find real-life uses of the hash character in existing sites that would conflict with this proposed usage pattern, then perhaps another character could be used. I rather like '@foo', or maybe even a combination such as '@#foo'.

==== Including data in the middle of an element ====

Above, the examples show how an element can be logically included as the first or last child of another element. For including data into the middle of an element, we need to be a tiny bit more verbose and insert a dummy element (in this case a element) where the included content should go:

<pre>
Our head office is in London at:

5 Kensington High Street 

SW7 1AA

</pre>

==== problems with ordered ids in class ====
Two problems:

1. class is an unordered set of values per HTML4. introducing ordering is a non-starter both from a violation of HTML4 spec perspective and likely requiring of rewriting HTML4 parsers to maintain an ordering where they currently don't.

<div style="margin-left:2em;border-left:thick solid #ccc;padding-left:1em;">
A reading of HTML 4.01, section 7.5.2 doesn't seem to claim that the class list is unordered.

It does claim that it's a "set" of class names, and in mathematical parlance sets are unordered by definition, and must not contain duplicates, but it's unlikely that the framers of the HTML 4.01 spec intended the world "set" to be interpreted in that way -- far more likely they were referring to the layman's definition of the word.

As far as parsers are concerned, DOM Level 2 HTML provides as "className" property as part of the HTMLElement interface, which is either directly used or is inherited by all DOM element nodes. The className is a string exactly reflecting the contents of the HTML class attribute, so should reflect their original order.

And any non-DOM, naive SGML or XML parser that encounters a class attribute will just parse it as a plain old string anyway, so the order should be retained.

[[User:TobyInk|TobyInk]] 08:34, 5 Feb 2008 (PST)
</div>

2. inclusion of arbitrary data (#baz) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]]. [[User:Tantek|Tantek]]

<div style="margin-left:2em;border-left:thick solid #ccc;padding-left:1em;">
This anti-pattern is only mentioned as a subheading to the more general anti-pattern of invisble metadata. My suggested pattern for inclusions does not hide metadata -- it merely references metadata elsewhere on the page. It is no more guilty of hiding metadata than any other suggested include pattern, so I fail to see how this is relevant.

[[User:TobyInk|TobyInk]] 08:36, 5 Feb 2008 (PST)
</div>

===Simple class name===

:<code><foo id="birmingham" class="locality">Birmingham</foo></code>

then:

:<code><foo class="adr includes-birmingham">[...]</foo></code>

Some other possible variants are:

:<code><foo class="adr birmingham">[...]</foo></code>

or

:<code><foo class="adr part-microformat birmingham">[...]</foo></code>

or

:<code><foo class="adr use-birmingham">[...]</foo></code>

or

:<code><foo class="adr uses-birmingham">[...]</foo></code>

or

:<code><foo class="adr include-birmingham">[...]</foo></code>

or

:<code><foo class="adr locality-birmingham">[...]</foo></code>

or

:<code><foo id="birmingham">Birmingham</foo></code>

:[...]

:<code><foo class="adr locality-birmingham">[...]</foo></code>

(originally suggested by [[User:AndyMabbett|Andy Mabbett]] in <http://microformats.org/discuss/mail/microformats-discuss/2008-January/011422.html et seq.)

==== problems with arbitrary id values in class attributes ====
In short: similar to [[#problems_with_ordered_ids_in_class|problems with ordered ids in class]], inclusion of arbitrary data (birmingham) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].

Longer: The value of an <code>id</code> attribute on an element is essentially an arbitrary string used to uniquely identify that element in the context of the document. Thus the re-use of such an arbitrary string (e.g. "birmingham") in a class attribute is an instance of including arbitrary data in the class attribute, which is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].

[[User:Tantek|Tantek]]

* In this proposal, the class name is not "arbitrary data", since it uses a semantically valid IDs; and is semantically logical. In the cited page the use of data in class names is deprecated as "another form of invisible metadata". This proposal involves no more "invisible metadata" than do the existing include patterns. [[User:AndyMabbett|Andy Mabbett]] 00:52, 4 Feb 2008 (PST)
** existing include patterns use <code>href</code> and <code>data</code> (not <code>class</code>) attributes which are both of type URI to point to a fragment identifier. arbitrary links are proper semantic use of URI attributes per HTML4. however in a class attribute, arbitrary links are no more than arbitrary data, and are thus an example of [[anti-patterns#data_in_class_attributes|the documented anti-pattern]]. (Unsigned comment by [[User:Tantek|Tantek]])
*** The fragment identifier is not data. Well, OK, it is data in the sense that virtually everything is data, but, in the example above, the link itself is not address data -- it's a pointer to data... information about where the real data might be found... it's ''metadata''. [[User:TobyInk|TobyInk]] 07:42, 6 Feb 2008 (PST)

===Use <code>@</code> to Reference IDs===

Don't <code>"include"</code> your data, you could perhaps just reference them.

<pre><foo id="me" class="fn">Fred</foo></pre>

<pre><bar class="me@url">http://wherever.com/</bar></pre>

parsers instead of replacing data can then just append their data?

Suggested in: [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011470.html microformats-discuss/2008-February/011470.html]

==== problems with using at ref to id ====
* Too verbose http://microformats.org/discuss/mail/microformats-discuss/2008-February/011473.html
* Inclusion of arbitrary data <code>@</code>, "[[anti-patterns#data_in_class_attributes|documented anti-pattern]]" as pointed out on microformats discuss http://microformats.org/discuss/mail/microformats-discuss/2008-February/011479.html

===Use a Class Create method===

Create a class such as <code>"data"</code> in the following example, or any unique class name much the same as we do already with <code>id=""</code>.

Examples could be <code>"reviewer"</code> or <code>"me"</code>.

example,
<pre>

Foo

<a class="email" href="mailto:foo@bar.com">email foo@bar.com</a>
</pre>

Use an empty span to reference your unique class name with class <code>"include *"</code> anywhere you would
like the created class to be included.

example,
<pre>

<a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
</pre>

The result "could" turn out much like this:

example,
<pre>
Foo
<a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
</pre>

====Problems====

* If class="include data" is taken to mean "include all elements with a class name of 'data'", then the element will include itself and potentially introduce problems with recursion. [[User:TobyInk|TobyInk]] 02:23, 11 Feb 2008 (PST)
** Not Necessarily so, It would depend on Parsing rules. [[User:WebOrganics|Martin McEvoy]] 17:19, 11 Feb 2008 (GMT)

=== Use property inheritance from groups, implicit member/group relations (by containment) and explicit property/object relations (by reference) ===

This proposal is only presented for the record. The main reason it has been discarded is because "the use of [[rev]], and any new microformats values for rev, has been deprecated for several reasons. See [[rev#Should_rev_even_be_used|Should rev even be used]].".

It is really two proposals in one:
* property inheritance from group elements: if an object is part of a group, it inherits the properties associated with this group.
* explicit property referencing. This technique provides an alternative to the current technique of associating by containment a property with an object, or sub-property with parent property. With the suggested new technique, the property or sub-property does not have to be contained (resp.) by the object or parent property: the association is made explicitly via a rev link.

Example:

<pre>
Our company has office locations in <a href="#adrlist1" rev="locality">San Francisco</a>:
<ul id="adrlist1">
<li id="adr1" class="adr">665 3rd Street, and</li>
<li id="adr2" class="adr">123 Folsom</li>
</ul>
</pre>

This example would be interpreted as:
* adr1 and adr2 belong to the group adrlist1 by containment.
* "San Francisco" is the locality property of the adrlist1 group.
* hence, adr1 and adr2 inherit the locality property from adrlist1 since they are not overriding it.

=== Use property inheritance from groups, explicit group/member referencing and implicit property relations (by containment) ===

<pre>
Our company has office locations in San Francisco:
<a id="adr1" href="#adrlist1" rel="group" class="adr">665 3rd Street,
and <a id="adr2" href="#adrlist1" rel="group" class="adr">123 Folsom
</ul>
</pre>

This technique use: property inheritance from group and explicit relationships between groups and members. The HTML code actual reflects the meaning of the sentence: the items following the columns belong to a group from which they inherit a property (locality).

This example would be interpreted as:
* adr1 and adr2 belong to the #adrlist1 group (by reference).
* locality is associated with #adrlist1 by containment
* adr1 and adr2 inherit the locality property "San Francisco" from the group they belong to, since they are not overriding it.

== contributors ==
* [[User:TobyInk|Toby Inkster]]
* [[User:AndyMabbett|Andy Mabbett]]
* [[User:WebOrganics|Martin McEvoy]]

== Related Pages ==
{{include-pattern-related-pages}}

hcard-issues

2008-02-08T19:01:54Z

Guillaume Lebleu: Added FN required issue in hCard in HTML tables

<h1> hCard issues </h1>
{{TOC-right}}
These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documedabnted here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] and the [[hcard-issues-resolved|hCard resolved issues]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].

See other [[issues]] also.

== closed issues ==
See: [[hcard-issues-resolved]]

== resolved issues ==
See: [[hcard-issues-resolved]]

== issues ==
Please add new issues to the '''bottom''' of the list by copy and pasting the [[hcard-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

=== 2006 ===

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''There should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself.''
*#* Quite often I see "a" webpage accessible with several different URLs. Typically 1 URL is the "preferred" URL, expected to have a long lifetime. Sometimes other URLs are "convenience" URLs that may have been linked to in the past, but are expected to go away soon, which resolve to the same file (the "latest version"). Then there are "archive" URLs that show an exact copy of that webpage as it appeared some time in the past. I think we want to always use the "preferred" URL, no matter which of those URLs we happen to stumble upon first -- so the URL is not actually redundant. (How exactly is it "accessibility-damaging" for a page to link to itself? Could you explain or add a link to an explanation?) --[[User:DavidCary|DavidCary]] 17:44, 5 Apr 2007 (PDT)
*#**"''How exactly is it "accessibility-damaging" for a page to link to itself?''" - Novice user clicks on link; nothing (it appears) happens. Repeat ad infinitum, until user leaves site to do something else. [[User:AndyMabbett|Andy Mabbett]] 02:43, 6 Apr 2007 (PDT)
*#*A: ACCEPTED THEORETICAL. While I tend to agree with the accessibility guidelines/issues noted herein in theory, to make this a real world issue worthy of higher priority, we need documentation of examples in the wild where the URL of an hCard or hCalendar event is the URL of the page itself, so that we can use those examples to inform brainstorming towards a solution. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
*#** Examples in the wild where the URL of an hCard is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes] page at SXSW 2007 (1 of 1000+ bands). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCard for The Pipettes to indicate that the page itself is the URL for the hCard.
*#*** See also the proposal to use this pattern in [[representative-hcard]]
*#** Examples in the wild where the URL of an hCalendar event is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes at La Zona Rosa] page at SXSW 2007 (1 of 1000+ concerts, yes, same page as the page for The Pipettes the org). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCalendar event for The Pipettes at La Zona Rosa to indicate that the page itself is the URL for the hCalendar event.
*#** This is also an [[hreview-issues|hReview issue]] and any other microformat which has a "url" property. Examples where the URL of an (potential) hReview *item* is the URL of the page itself:
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions of potential hReview items/products with reviews on their item pages).

=== 2007 ===
* {{OpenIssue}} 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# RFC2426 'type' values cannot be localized/internationalized in hCard. In the example below, there is no solution to mark the Spanish version with a type of 'home' since the RFC2426 values are defined in English. abbr-design-pattern would suggest using abbr, but 'Casa' is not an abbreviated form of 'home', therefore the currently recommended version (below) is not valid.<pre><nowiki>

<abbr class="type" title="home">Casa</abbr> (preferido):
+1.415.555.1212

</nowiki></pre>
*#* REJECTED. TOO LITTLE INFORMATION. Please provide the precise URL to the specific statement on the accessify forum discussion that asserts that using abbr is not valid. Please also provide a precise URL to a *real world* (as opposed to an artificially constructed test case) example in the wild of an non-English hCard which attempts to specify RFC2426 type information on a "tel" property and fails to do so.
*#* REOPENED and clarified (Also removed Accessify reference pulled from [[http://microformats.org/wiki?title=accessibility&oldid=12943 original raising]]).
*#*# Though erroneously first raised on the accessibility page, this is not an accessibility issue. It is an HTML semantics issue for internationalization. <code>abbr[title]</code> should be an expanded form of <code>abbr</code> contents, in the same language.
*#*# There are real-world non-English examples in the current Mac OS 10.5 (Leopard) developer seed. This code example illustrates the point sufficiently.
*#*# Please leave the clarification as-is even if you feel you must RE-REJECT (add-on, don't revert). My original points were lost when they were taken out of context and moved here. -[[User::JamesCraig|JamesCraig]]

<div class="vevent">
* {{OpenIssue}} 2007-03-19 raised by [[User::ChristinaHope|Christina Hope]]
<div class="description">
*# ''Does Microsoft Outlook 2003 allow the use of the "role" property? I have added it to all of my hCards and it is not appearing. Am I doing something wrong?''
*#** URL? (if no URL to a demonstrative example is provided within a year of this issue being raised, it will be closed as REJECTED INSUFFICIENT INFORMATION.)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2007-03-31 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)
*#* Note also the forthcoming [http://www.euref-iag.net/ European Terrestrial Reference System 89 schema] (See also [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 on Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 Apr 2007 (PDT)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2007-04-19 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
*#How should we handle [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Old Style and New Style dates] (i.e. Julian calendar vs. Gregorian), in DoB? For instance, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], born "10 February [O.S. January 29] 1890". Should the hCard spec. specify New Style, using the [[abbr-design-pattern]] (or its successor) if necessary: <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?
</div>
</div>

===2008===

<div class="vevent">
* {{OpenIssue}} 2008-01-01 raised by [[User:AndyMabbett|Andy Mabbett]] in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011182.html microformats-discuss/2008-January/011182.html]
<div class="description">
*# The "n" optimisation rules (nickname, fn) should not apply where the fn is on part of adr or label: e.g <code><nowiki>
New York</nowiki></code>; <code><nowiki>Asia</nowiki></code>, since, in these examples, "Asia" is not a nickname, "New" is not a given-name and "York" is not a family-name. (see also [[hcard-brainstorming#Named_locations]])
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-01-09 2008- moved from vcard-suggestions
<div class="description">
*#We can't have a generic type name cause we have to localize in French. so, for us, hCard work phone number is: <nowiki><div class="tel">Travail : 0321596224</div></nowiki>. How will a bot recognize that type ? We cannot specify every types in every languages in the specification. That's why i think something like this would be better: <nowiki>Travail : 0321596224</nowiki> Please, use class and id attributes ONLY for micro formats specifications ! XML #cdata and #data are localized ! Thanks !
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-02-02 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
*# The "<code>n</code>" optimisation rules (<code>nickname</code>, <code>fn</code>) should not apply where the <code>fn</code> is also the <code>role</code> or <code>title</code>: e.g <code><nowiki>
Webmaster</nowiki></code>; <code><nowiki>Duty Manager</nowiki></code>, since, in these examples, "Webmaster" is not a nickname, "Duty" is not a given-name and "Manager" is not a family-name.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-02-06 raised by [[User:Guillaume Lebleu| Guillaume Lebleu]]
<div class="description">
*# It seems to me that FN has been reused beyond its original vCard scope of person names, to cover any name. This led to the fn/title debate, but it seems some implementors are confused between following the vCard semantics (FN only for person names) or the hCard ones (FN for any name). See. http://cinematreasures.org/theater/365/, which uses an empty FN, resulting in their vCard not being detected by Operator, only the address.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-02-07 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
*# The "<code>fn</code>" optimisation rule should not apply where the full <code>fn</code> is also the <code>nickname</code>: e.g <code><nowiki>Plastic Bertram</nowiki></code>, since a given-name+family-name pair is not usually a nickname. (But how to deal with pseudonyms such as "Maurice Micklewhite (known professionally as Michael Caine)"?)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-02-07 raised by [[User:AndyMabbett|Andy Mabbett]] in [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011552.html microformats-discuss/2008-February/011552.html]
<div class="description">
*# Is "n" optional or mandatory? The spec says yes (with exceptions) the cheat-sheet says no. Parsers and common practice seem to indicate not.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-02-07 raised by [[User:AndyMabbett|Andy Mabbett]] in [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011552.html microformats-discuss/2008-February/011552.html]
<div class="description">
*# "<code>nickname</code>" and "<code>fn</code>" optimisation does not work for some or all names in Asian languages. See [http://zh.wikipedia.org/wiki/%E6%B9%AF%E5%A7%86%C2%B7%E5%85%8B%E9%AD%AF%E6%96%AF Tom Cruise on Chinese Wikipedia], where the <code>fn</code> and nickname are the same. This could be partly remedied by not applying such optimisation when the page's (or element's) language is set to one of a set of affected languages (may also apply to other languages, such as Greek). '''Cpmment from people fluent in such languages would be welcome.'''
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-02-08 raised by [[User:Guillaume Lebleu| Guillaume Lebleu]]
<div class="description">
*# The required FN makes it difficult to use hCard in HTML Tables without resorting to hiding information (as in http://www.bo.ingv.it/contents/INGV-Bologna/Staff.html) or using the [[include-pattern]]. Perhaps FN should not be required if some N are present. Originally raised in [http://rbach.priv.at/Microformats/IRC/2008-02-08#T181749]
</div>
</div>

== template ==

{{issues-format}}

== related pages ==
{{hcard-related-pages}}</nowiki>

irc-people

2008-02-07T18:30:47Z

Guillaume Lebleu: Added glebleu to IRC list

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

* {{irc user|Adam Ballai|AdamBallai|-700/-700}}
* {{irc user|Adam Craven|AdamCraven|+0000}}
* {{irc user|Alexander Graf|AlexanderGraf|+0100}}
* {{irc user|Tomasino|aloneone|-0500}}
* {{irc user|AmanuelTewolde|Amanuel|-0500/-0400}}
* {{irc user|Amette|amette|+1000}}
* {{irc user|Amir Guindehi|AmirGuindehi|+1000}}
* {{irc user|Ajaswa|Andrew Jaswa|-0500}}
* {{irc user|AnselHalliburton|anselxyz|-0800/-0700}}
* {{irc user|Ashe Dryden|Ashe|-600}}
* {{irc user|Ashley|Ashley|+1000}}
* {{irc user|Azathoth|Florian Beer|+1000}}
* {{irc user|Tyler Roehmholdt|Baristo|-0800/-0700}}
* {{irc user|BenjaminCarlyle|BenjaminCarlyle|+1000}}
* {{irc user|HenriBergius|bergie|+0200/+0300}}
* {{irc user|Ben Ward|BenWard|+0000}}
* {{irc user|BenWest|bewest|-0800/-0700}}
* {{irc user|B.K._DeLong|bkdelong|-0500/-0400}}
* {{irc user|Robert|blueace|+0100}}
* {{irc user|BluesMoon|bluesmoon|+0530}}
* {{irc user|BobChao|BobChao|+0800}}
* {{irc user|Bob Jonkman|BobJonkman|-0500/-0400}}
* {{irc user|Boneill|boneill|+0000}}
* {{irc user|Brian|briansuda|+0000}}
* {{irc user|TimT|bringo|-0800/-0700}}
* {{irc user|Briski|Briski|+0000}}
* {{irc user|BryanL|BryanL|-0500/-0400}}
* {{irc user|BryanRieger|Bryan Rieger|+0000}}
* {{irc user|Bug-E|Bug-E|+0200}}
* {{irc user|CarlaHufstedler|carlamagpie|-0500/-0400}}
* {{irc user|Colin_Barrett|cbarrett|-1000}}
* {{irc user|ColinDDevroe|cdevroe|-0500/-0600}}
* {{irc user|Cgriego|cgriego|-0600/-0500}}
* {{irc user|Charlvn|Charl|+0200/+0200}}
* {{irc user|CharlesRoper|charles_r|0000/+0100}}
* {{irc user|ChristopherStJohn|cks|-0600/-0500}}
* {{irc user|Cloud|Cloud|+0000}}
* {{irc user|Cruster|cruster|+0200}}
* {{irc user|Csarven|csarven|-0500/-0400}}
* {{irc user|ChrisBrentano|ctb|-0800/-0700}}
* {{irc user|DanC|DanC|-0600/-0500}}
* {{irc user|DanielBurka|DanielBurka|-0400}}
* {{irc user|DanielJohnLewis|danieljohnlewis|0000}}
* {{irc user|DannyAyers|danja|+0100/+0200}}
* {{irc user|Dave Cardwell|davecardwell|+0000}}
* {{irc user|DavidMead|DavidMead|-0400}}
* {{irc user|DavidRussell|davidrussell|-0600/-0500}}
* {{irc user|DBounds|Darren Bounds|-0500
* {{irc user|DenisDefreyne|ddfreyne|+0100/+0200}}
* {{irc user|DeanEro|deanero|-0800/-0700}}
* {{irc user|DeepText|Deep Text|-0800/-0700}}
* {{irc user|DerrickPallas|DerrickPallas|-0800/-0700}}
* {{irc user|DimitriGlazkov|dglazkov|-0600/-0500}}
* {{irc user|DiegoBudny|DiegoBudny|-unspecified-}}
* {{irc user|Dan Kubb|dkubb|-0800/-0700}}
* {{irc user|DrErnie|DrErnie|-0800/-0700}}
* {{irc user|DrewMcLellan|drewinthehead|+0000/+0100}}
* {{irc user|DrewBell|droob|-0600/-0500}}
* {{irc user|DimitriosZachariadis|dzach|+0200/+0300}}
* {{irc user|DydimusTK|dydimustk|-0600}}
* {{irc user|Ed Summers|edsu|-0500/-0400}}
* {{irc user|Enric|Enric|-0800/-0700}} (alt sp "enric")
* {{irc user|Evan|evanpro|-0500}}
* {{irc user|ChrisMessina|factoryjoe|-0800/-0700}}
* {{irc user|Fil|Fil|+0200}}
* {{irc user|CFinke|Finke|-0700/-0600}}
* {{irc user|MarkoMrdjenovic|friedcell|+0100/+0200}}
* {{irc user|GarethR|garethr|+0000/+0100}}
* {{irc user|Grantbow|Grantbow|-0800/-0700}}
* {{irc user|Griffin|Griffin|-0600/-0500}}
* {{irc user|Guillaume Lebleu|glebleu|-0800}}
* {{irc user|Aubergine10|Guy Fraser|+0100/+0000}}
* {{irc user|HenrichPoehls|HenrichP|+0100}}
* {{irc user|IanHickson|Hixie|-0800/-0700}}
* {{irc user|Hlb|hlb|+0800-0700}}
* {{irc user|EdwardOConnor|hober|-0800/-0700}}
* {{irc user|Ichigo|ichigo|+1000}}
* {{irc user|Alper|illustir|+0100}}
* {{irc user|Inkbase|inkbase|-0800/-0700}}
* {{irc user|IwaiMasaharu|iwaim|+0900}}
* {{irc user|Izo|IZO|-unspecified-}}
* {{irc user|JamieKnight|JamieKnight|+1000/0000}}
* {{irc user|JoeGregorio|jcgregorio|-unspecified-}}
* {{irc user|WizardIsHungry|jcw9|-0500/-0400}}
* {{irc user|Adactio|Jeremy Keith|+0000}}
* {{irc user|jrodgers|JesseRodgers|-0500}}
* {{irc user|JasonK|jkridner|-0600/-0500}}
* {{irc user|JeffMcNeill|jeffmcneill|-1000}}
* {{irc user|JimboJW|jimbojw|-0600/-0500}}
* {{irc user|Jonathan_Arkell|jonnay|-0700/0600}}
* {{irc user|JosephHolsten|josephholsten|-0600/-0500}}
* {{irc user|JulianStahnke|julianstahnke|+0000}}
* {{irc user|Kapowaz|kapowaz|+0000/+0100}}
* {{irc user|Keri Henare|kerihenare|+1200}}
* [http://epeus.blogspot.com/ KevinMarks] (-0800/-0700)
* {{irc user|RyanKing|kingryan|-0800/-0700}}
** [http://theryanking.com/blog/archives/2006/04/19/office-hours/ Office hours]: Wednesday, 21:00 UTC
* {{irc user|Lachlan Hunt|Lachy|+1000/+1100}}
* {{irc user|Levitation|levitation[A]|+0200/+0300}}
* {{irc user|Linmic|linmic|+0800-0700}}
* {{irc user|MarkNg|madness|+0000/+0100}}
* {{irc user|Mark Mansour|Mark Mansour|+1100}}
* {{irc user|MarkNormanFrancis|Mark Norman Francis|+0000/+0100}}
* {{irc user|MattBowen|Matt Bowen|-0500/-0400}}
* {{irc user|MattisManzel|Mattis Manzel|+0100/+0200}}
* {{irc user|CiaranMc|McNulty|+0000/+0100}}
* [[mfbot]] - a bot which logs all edits to this wiki. It appends a number with a '+' or '-' sign, to indicate the number of characters added or removed as a result of the edit.
* {{irc user|Mike|Michael McCracken(mmc)|-0800/-0700}}
* {{irc user|MikeKaply|mkaply|-0600/-0500}}
* {{irc user|SteveIvy|monkinetic/redmonk|-0700}}
* {{irc user|RobManson|nambor|+1000}}
* {{irc user|neuro|neuro|-unspecified-}}
* {{irc user|Niekie|niekie|+0100/+0200}}
* {{irc user|NTollervey|ntoll|+0000/+0100}}
* {{irc user|Andy Pemberton|pembertona|-0500/-0400}}
* {{irc user|Phae|Phae|+0000/+0100}}
* {{irc user|PriitLaes|plaes|+0200/+0300}}
* {{irc user|ChrisCasciano|pnhChris|-0500/-0400}}
* {{irc user|PetarPopov|popov|-0800/-0700}}
* {{irc user|DavidOsolkowski|qid|-0500}}
* {{irc user|RCanine|RCanine|-0500/-0400}}
* {{irc user|Remi|Remi|-0500/-0400}}
* {{irc user|RobertBachmann|RobertBachmann|+0100/+0200}}
** Office hours: <s>Wednesday, 18:00-20:00 UTC</s> (Currently no office hours}}
* {{irc user|Ronnos|Ron Kok|+0000}}
* {{irc user|SarahWorsham|sazbean|-0500/-0400}}
* {{irc user|ScottNelle|snelle|-0500/-0400}}
* {{irc user|ScottRozic|gravitas|-0500/+0100}}
* {{irc user|Dana Benson|Snowden|-0800/-0700}}
* {{irc user|Smackman|Steve Farrell|-0800/-0700}}
* {{irc user|SpikeUK|SpikeUK|+0000/+0100}}
* {{irc user|Steve Ganz|SteveGanz|-0800/-0700}}
* {{irc user|Stii|Stii|+0200 GMT}}
* {{irc user|ReinierZ|surial|+0100 GMT}}
* {{irc user|SuperPhly|SuperPhly|-600/-500}}
* {{irc user|SyedSRahman|syedsrahman|+0530}}
* sym[[User:LynX|lynX]] or (better) [[User:LynX|lynX]] on [http://about.psyc.eu PSYC] (+0100}}
* {{irc user|DavidLehn|taaz|-0500/-0400}}
* {{irc user|Tantek|Tantek|-0800/-0700}}
* {{irc user|Trovster|trovster|-0800/-0700}}
* {{irc user|Vadania|vadania|-0600/-0700}}
* {{irc user|Vant|vant|+0900}}
* {{irc user|Victor|victor|+0100/+0200}}
* {{irc user|V-I-P|V-I-P|+0100/+0200}}
* {{irc user|KrissWatt|VoodooChild|+0000/+0100}}
* {{irc user|WebOrganics|weborganics|+0100}}
* {{irc user|JacksonWilkinson|whafro|-0500/-0400}}
* {{irc user|Richard Conyard|WhiskeyM|+0000}}
* {{irc user|Veeliam|William Lawrence|-0800/-0700}}
* {{irc user|StevenWoods|woodss|+0000 GMT}}
* {{irc user|Wojciech|wzajac|+0100/+0200}}
* {{irc user|Ianloic|yakk|-0800/-0700}}
* {{irc user|LarsStrojny|mastaYoda|+0100}}
* {{irc user|ZimbaTm|zimbatm|+0100}}
* {{irc user|FoundAtion|Foundation|-0800}}

namespaces-inconsistency-issue

2008-02-07T00:47:08Z

Guillaume Lebleu: /* Sympathetic to the Cause */

=Introduction=

This page outlines a disputed inconsistency that the Microformat's community has had for a number of years. Namely, in the way the community defines "namespace" and the position it takes against that definition of a namespace.

=Brief Definitions=

Here are the widely accepted definitions for context, scope, namespace, fully qualified namespace, and emulated namespace:

;context
:A context is an enclosing structure that provides semantic meaning to the elements that it encloses.

;scope
:A scope is an enclosing context where values and expressions are associated. The term is interchangeable with context.

;namespace
:A namespace is a named scope/context.

;fully qualified namespace
:Fully qualified namespaces remove all ambiguity from a name. An example of a fully qualified namespace is: http://purl.org/dc/elements/1.1/creator, which is a fully qualified namespace for the Dublin Core property named 'creator'. In C++ std::string is an example of a fully qualified namespace.

;emulated namespace
:A namespace can be emulated by using an identifer naming convention. For example, png_create_write_struct, png_get_signature, png_read_row, png_set_invalid are examples of C functions that use an emulated namespace called 'png'.

=Required Changes=

These are the changes that would need to be made to the [[namespaces]] page to bring the Microformats definition of a namespace in line with the commonly cited definition of a namespace.

* The five brief definitions on context, scope, namespace, fully qualified namespace, and emulated namespace should be included on the page.
* Citations to more detailed definitions from reputable sources should be included on the page, the list of literature at the end of this page would be a good starting point.
* It should be made clear that Microformats use context, scope, namespaces as a general concept, and emulated namespaces in certain situations.
* It should be made clear that Microformats do not use fully qualified namespaces for class names, data, or any other Microformatted content.

=Logic=

==Microformats Use Context, Scope and Namespaces==
The following is an example of pure context and pure scope:

Example 1:
<pre>
var A;
{
var B;
{
var C;
}
// at this point, A and B are accessible in this context/scope, but C is not.
}
</pre>

The example above demonstrates what a pure context and a pure scope look like. The curly-braces are what denote the change in scope from one scope to the next. For example, the variable named C only exists in the inner-most scope.

The following is an example of namespaces (a namespace is a named scope):

Example 2:
<pre>
var A;
NAMESPACE_X {
var B;
NAMESPACE_Y {
var C;
}
// at this point, A and B are accessible in this context/scope, but C is not.
}
</pre>

The only change from Example 1, is that now we've named each scope - when you name a scope, it is called a namespace. There are two namespaces defined in this example, NAMESPACE_X and NAMESPACE_Y.

Example 2 can be extended to HTML quite easily:

Example 3:
<pre>
<div>
Manu Sporny
</div>
</pre>

The example above is similar to Example 2, but it uses HTML markup. The <div> and tags are what denote the change in scope. The SPAN element is in the DIV namespace in this example.

Example 4:
<pre>
<div class="vcard">
Manu Sporny
</div>
</pre>

The example above now has two top-level named scopes that are defined, the DIV namespace and a new namespace called "vcard" - the currently active Microformat namespace. A named scope is a namespace, thus - Microformats use context/scope and namespaces.

==Microformats Use Emulated Namespaces==

An emulated namespace is a named scope that uses the same prefix to denote semantic similarity. An example of an emulated namespace is:

Example 6:
<pre>
png_create_write_struct
png_get_signature
png_read_row
png_set_invalid
</pre>

The example above uses "png" as the emulated namespace identifier.

Microformats use emulated namespaces in hAtom:

Example 7:
<pre>
entry-title
entry-content
entry-summary
</pre>

The example above uses "entry" as the emulated namespace identifier. The claim that "entry" is a namespace is contested by the primary editor of hAtom. However, "If it quacks like a duck, walks like a duck, and looks like a duck - it's a duck."

==Microformats as overlapping trees==
Microformats attempt to use a single vocabulary. Therefore, properties like URL, have one definition across all formats, it makes little sense to have hcard:url, hreview:url, hcalendar:url, etc. They all mean the same thing, therefore there is no reason to group them, scope them or namespace them. If you think of each format as a tree structure mapped onto HTML elements, some portions of various trees will overlap and share branches. Scoping and namespacing would prevent these things from happening, but they occur in microformats all the time.

If an hCard is within an hCalendar, all shared properties (i.e. URL) are mixed between both formats. These are the points at which the trees overlap. This was done by design. It does create some limitation, but these where not great enough to out weight the benefits to publishers.

*The "overlapping trees" model causes problems when (in the above example) there are two, different URLs:

::<pre><nowiki>
<a href="example.com/johndoe">John Doe</a>
would like to invite you to
<a href="example.net/widget-event">a meeting about widgets</a> on...
</nowiki></pre>

:If John Doe is marked up as an hCard and as the event's <code>organiser</code> (both perfectly reasonable actions), his URL will become the URL for the event, whereas the latter should be used. Such overlaps could be dealt with by parsing rules, but these would be many and convoluted, and may be counter-productive where the URL is shared. This has already been an issue for me, on live pages. [[User:AndyMabbett|Andy Mabbett]] 02:42, 6 Feb 2008 (PST)

==Microformats Do Not Use Fully Qualified Namespaces==

There is agreement on Microformats not using fully qualified namespaces. For example, this is verboten:

Example 8:
<pre>
<div xmlns:vc="http://microformats.org/wiki/vcard-namespace#" class="vc:vcard">
Manu Sporny
</div>
</pre>

The above example uses a [http://en.wikipedia.org/wiki/Qname QName] to specify a fully qualified namespace for the FN class in the VCARD container. This is confusing for beginners, and difficult to author. The difficulty in understanding fully qualified namespaces, and the difficulty in authoring fully qualified namespaces are the primary reasons that fully qualified namespaces are not used in Microformats.

=Definitions=

Here are excerpts from the definitions and links to further definitions supporting the arguments listed on this page.

The general definition of context is:

<blockquote style="background-color:#fffff4; border-style:dashed; padding:1em;">
Discourse that surrounds a language unit and helps to determine its interpretation.
</blockquote>
:--- [http://wordnet.princeton.edu/perl/webwn?s=context Wordnet: context]

The definition of scope is:

<blockquote style="background-color:#fffff4; border-style:dashed; padding:1em;">
In computer programming, scope is an enclosing context where values and expressions are associated. Various programming languages have various types of scopes. The type of scope determines what kind of entities it can contain and how it affects them -- or semantics.

Scopes can:

* contain declarations or definitions of identifiers;
* contain statements and/or expressions which define an executable algorithm or part thereof;
* nest or be nested.

A namespace is a scope that uses the enclosing nature of the scope to group logically related identifiers under a single identifier. Thus, scopes can affect the name resolution for their contents.
</blockquote>
:--- [http://en.wikipedia.org/wiki/Scope_%28programming%29 Wikipedia: scope]

The general definition of namespace is defined as:

<blockquote style="background-color:#fffff4; border-style:dashed; padding:1em;">
...a namespace is an abstract container providing context for the items (names, or technical terms, or words) it holds and allowing disambiguation of items having the same name (residing in different namespaces)...
</blockquote>
:--- [http://en.wikipedia.org/wiki/Namespace Wikipedia: namespace]

The Computer Science definition of namespace is:

<blockquote style="background-color:#fffff4; border-style:dashed; padding:1em;">
A namespace is an abstract container or environment created to hold a logical grouping of unique identifiers (i.e., names). An identifier defined in a namespace is associated with that namespace. The same identifier can be independently defined in multiple namespaces. That is, the meaning associated with an identifier defined in one namespace may or may not have the same meaning as the same identifier defined in another namespace. Languages that support namespaces specify the rules that determine which namespace an identifier (i.e., not its definition) belongs.
</blockquote>
:--- [http://en.wikipedia.org/wiki/Namespace_%28programming%29 Wikipedia: Namespace (computer science)]

The Computer Science definition of an "emulated namespace" is:

<blockquote style="background-color:#fffff4; border-style:dashed; padding:1em;">
In programming languages that do not provide language support for namespaces, namespaces can be emulated to some extent by using an identifier naming convention. For example, C libraries such as Libpng often use a fixed prefix for all functions and variables that are part of their exposed interface. Libpng exposes identifiers such as:

*png_create_write_struct
*png_get_signature
*png_read_row
*png_set_invalid

This gives reasonable assurance that the identifiers are unique and can therefore be used in larger programs without fear of identifier naming collisions.
</blockquote>
:--- [http://en.wikipedia.org/wiki/Namespace_%28computer_science%29#Emulating_namespaces Wikipedia: Namespace emulation]

The Computer Science definition of a "fully qualified namespace" is:

<blockquote style="background-color:#fffff4; border-style:dashed; padding:1em;">
In computer programming, a fully qualified name is an unambiguous name that specifies which object, function, or variable a call refers to absolutely. To fully-qualify most often means to explicitly refer to namespaces that would otherwise be implicit because of the scope of the call.
</blockquote>
:--- [http://en.wikipedia.org/wiki/Fully_qualified_name Wikipedia:fully qualified name]

=History=

In June of 2007, while discussing what should be the name of a song, album or audio recording for hAudio, [http://microformats.org/discuss/mail/microformats-new/2007-June/000511.html it was suggested that TITLE be re-used from hCard]. This kicked off a debate about whether it would be appropriate to re-use TITLE because [http://microformats.org/discuss/mail/microformats-new/2007-June/000512.html TITLE was previously defined in hCard as "job title"]. Manu pointed out that [http://microformats.org/discuss/mail/microformats-new/2007-June/000511.html this was not the proper English definition for TITLE], would confuse authors, and inquired as to why TITLE was defined in such a constrained way. It was shown that [http://microformats.org/discuss/mail/microformats-new/2007-June/000512.html TITLE re-used the definition of TITLE from the VCARD specification], and since TITLE had been set as such, re-defining it to become in-line with the English definition of TITLE would have ramifications on hCard implementations out in the field.

A suitable replacement for TITLE was discussed and [http://microformats.org/discuss/mail/microformats-new/2007-October/001009.html FN was adopted for hAudio].

Several months later, Martin McEvoy [http://microformats.org/discuss/mail/microformats-new/2008-January/001375.html raised the issue again] - that FN is not a suitable replacement for the title of an audio recording. Manu [http://microformats.org/discuss/mail/microformats-new/2008-February/001401.html argued that TITLE should be brought in line with the English definition] once again, and another argument about namespacing started on the microformats-new mailing list. This discussion revolved around an assertion that Manu was making about Microformat's [http://microformats.org/wiki/namespaces having a stance against namespacing], but then turning around and [http://microformats.org/discuss/mail/microformats-new/2008-February/001401.html inconsistently using "emulated namespaces"] as a replacement when there was no other option but to namespace (such as in hAtom - "entry-title", "entry-summary", "entry-description")

Manu asserted further that the community has an inconsistent stance on namespaces because the community's [http://microformats.org/discuss/mail/microformats-new/2008-February/001401.html definition of namespacing was not standard]. It deviated from the definition in the field of linguistics, programming language design, and mainstream computer science literature. To illustrate the point, it was shown what the standard definition of 'namespace' is using [http://microformats.org/discuss/mail/microformats-new/2008-February/001426.html a number of text books on the subject].

Manu is currently challenging the vague and inconsistent definition of namespace that is being used in the Microformats community and is asking for further refinement on the types of namespaces that are and are not allowed in the Microformats community.

=Sympathetic to the Cause=

Below is a list of people that would like the namespace inconsistency more directly addressed by implementing the changes listed above in the "Required Changes" section.

* [[User:ManuSporny|ManuSporny]] 07:54, 5 Feb 2008 (PST)
* [[User:Guillaume Lebleu|Guillaume Lebleu]] 04:46, 6 Feb 2008 (PST)

=Known anti-pattern=

Below is a list of people who believe the namespace anti-pattern has already been adequately addressed in [[namespaces]].

* [[User:EdwardOConnor|hober]] 11:44, 5 Feb 2008 (PST)

= Resolution =

Danny Ayers resolves pretty much all of the above regarding "namespaces" in his email:

http://microformats.org/discuss/mail/microformats-new/2008-February/001438.html

This resolution is being contested by Manu since none of the namespaces pages were updated as a result of the discussion. [[User:ManuSporny|ManuSporny]] 19:45, 4 Feb 2008 (PST)

=References=

References that support the commonly understood definition of namespace:

* [http://en.wikipedia.org/wiki/Namespace Wikipedia:namespace]
* [http://en.wikipedia.org/wiki/Scope_%28programming%29 Wikipedia:Scope]
* [http://wordnet.princeton.edu/perl/webwn?s=context Wordnet:context]
* History of Programming Languages II, By Thomas J. Bergin, Richard G. Gibson, p.265
* Programming and Problem Solving with C++, By Nell B. Dale, Chip Weems, p.369
* Computer-Aided Verification '90: Proceedings of a DIMACS Workshop, June 18-21, 1990. p.571
* Handbook of Object Technology By Saba Zamir, p.15

hcard-issues

2008-02-07T00:20:33Z

Guillaume Lebleu: /* Added issue to 2008 */

<h1> hCard issues </h1>
{{TOC-right}}
These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documedabnted here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] and the [[hcard-issues-resolved|hCard resolved issues]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].

See other [[issues]] also.

== closed issues ==
See: [[hcard-issues-resolved]]

== resolved issues ==
See: [[hcard-issues-resolved]]

== issues ==
Please add new issues to the '''bottom''' of the list by copy and pasting the [[hcard-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

=== 2006 ===

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''There should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself.''
*#* Quite often I see "a" webpage accessible with several different URLs. Typically 1 URL is the "preferred" URL, expected to have a long lifetime. Sometimes other URLs are "convenience" URLs that may have been linked to in the past, but are expected to go away soon, which resolve to the same file (the "latest version"). Then there are "archive" URLs that show an exact copy of that webpage as it appeared some time in the past. I think we want to always use the "preferred" URL, no matter which of those URLs we happen to stumble upon first -- so the URL is not actually redundant. (How exactly is it "accessibility-damaging" for a page to link to itself? Could you explain or add a link to an explanation?) --[[User:DavidCary|DavidCary]] 17:44, 5 Apr 2007 (PDT)
*#**"''How exactly is it "accessibility-damaging" for a page to link to itself?''" - Novice user clicks on link; nothing (it appears) happens. Repeat ad infinitum, until user leaves site to do something else. [[User:AndyMabbett|Andy Mabbett]] 02:43, 6 Apr 2007 (PDT)
*#*A: ACCEPTED THEORETICAL. While I tend to agree with the accessibility guidelines/issues noted herein in theory, to make this a real world issue worthy of higher priority, we need documentation of examples in the wild where the URL of an hCard or hCalendar event is the URL of the page itself, so that we can use those examples to inform brainstorming towards a solution. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
*#** Examples in the wild where the URL of an hCard is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes] page at SXSW 2007 (1 of 1000+ bands). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCard for The Pipettes to indicate that the page itself is the URL for the hCard.
*#*** See also the proposal to use this pattern in [[representative-hcard]]
*#** Examples in the wild where the URL of an hCalendar event is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes at La Zona Rosa] page at SXSW 2007 (1 of 1000+ concerts, yes, same page as the page for The Pipettes the org). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCalendar event for The Pipettes at La Zona Rosa to indicate that the page itself is the URL for the hCalendar event.
*#** This is also an [[hreview-issues|hReview issue]] and any other microformat which has a "url" property. Examples where the URL of an (potential) hReview *item* is the URL of the page itself:
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions of potential hReview items/products with reviews on their item pages).

=== 2007 ===
* {{OpenIssue}} 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# RFC2426 'type' values cannot be localized/internationalized in hCard. In the example below, there is no solution to mark the Spanish version with a type of 'home' since the RFC2426 values are defined in English. abbr-design-pattern would suggest using abbr, but 'Casa' is not an abbreviated form of 'home', therefore the currently recommended version (below) is not valid.<pre><nowiki>

<abbr class="type" title="home">Casa</abbr> (preferido):
+1.415.555.1212

</nowiki></pre>
*#* REJECTED. TOO LITTLE INFORMATION. Please provide the precise URL to the specific statement on the accessify forum discussion that asserts that using abbr is not valid. Please also provide a precise URL to a *real world* (as opposed to an artificially constructed test case) example in the wild of an non-English hCard which attempts to specify RFC2426 type information on a "tel" property and fails to do so.
*#* REOPENED and clarified (Also removed Accessify reference pulled from [[http://microformats.org/wiki?title=accessibility&oldid=12943 original raising]]).
*#*# Though erroneously first raised on the accessibility page, this is not an accessibility issue. It is an HTML semantics issue for internationalization. <code>abbr[title]</code> should be an expanded form of <code>abbr</code> contents, in the same language.
*#*# There are real-world non-English examples in the current Mac OS 10.5 (Leopard) developer seed. This code example illustrates the point sufficiently.
*#*# Please leave the clarification as-is even if you feel you must RE-REJECT (add-on, don't revert). My original points were lost when they were taken out of context and moved here. -[[User::JamesCraig|JamesCraig]]

<div class="vevent">
* {{OpenIssue}} 2007-03-19 raised by [[User::ChristinaHope|Christina Hope]]
<div class="description">
*# ''Does Microsoft Outlook 2003 allow the use of the "role" property? I have added it to all of my hCards and it is not appearing. Am I doing something wrong?''
*#** URL? (if no URL to a demonstrative example is provided within a year of this issue being raised, it will be closed as REJECTED INSUFFICIENT INFORMATION.)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2007-03-31 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)
*#* Note also the forthcoming [http://www.euref-iag.net/ European Terrestrial Reference System 89 schema] (See also [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 on Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 Apr 2007 (PDT)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2007-04-19 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
*#How should we handle [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Old Style and New Style dates] (i.e. Julian calendar vs. Gregorian), in DoB? For instance, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], born "10 February [O.S. January 29] 1890". Should the hCard spec. specify New Style, using the [[abbr-design-pattern]] (or its successor) if necessary: <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?
</div>
</div>

===2008===

<div class="vevent">
* {{OpenIssue}} 2008-01-01 raised by [[User:AndyMabbett|Andy Mabbett]] in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011182.html microformats-discuss/2008-January/011182.html]
<div class="description">
*# The "n" optimisation rules (nickname, fn) should not apply where the fn is on part of adr or label: e.g <code><nowiki>
New York</nowiki></code>; <code><nowiki>Asia</nowiki></code>, since, in these examples, "Asia" is not a nickname, "New" is not a given-name and "York" is not a family-name. (see also [[hcard-brainstorming#Named_locations]])
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-01-09 2008- moved from vcard-suggestions
<div class="description">
*#We can't have a generic type name cause we have to localize in French. so, for us, hCard work phone number is: <nowiki><div class="tel">Travail : 0321596224</div></nowiki>. How will a bot recognize that type ? We cannot specify every types in every languages in the specification. That's why i think something like this would be better: <nowiki>Travail : 0321596224</nowiki> Please, use class and id attributes ONLY for micro formats specifications ! XML #cdata and #data are localized ! Thanks !
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-02-02 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
*# The "n" optimisation rules (nickname, fn) should not apply where the fn is also the role: e.g <code><nowiki>
Webmaster</nowiki></code>; <code><nowiki>Duty Manager</nowiki></code>, since, in these examples, "Webmaster" is not a nickname, "Duty" is not a given-name and "Manager" is not a family-name.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-02-06 raised by [[User:Guillaume Lebleu| Guillaume Lebleu]]
<div class="description">
*# It seems to me that FN has been reused beyond its original vCard scope of person names, to cover any name. This led to the fn/title debate, but it seems some implementors are confused between following the vCard semantics (FN only for person names) or the hCard ones (FN for any name). See. http://cinematreasures.org/theater/365/, which uses an empty FN, resulting in their vCard not being detected by Operator, only the address.
</div>
</div>

== template ==

{{issues-format}}

== related pages ==
{{hcard-related-pages}}

hcard-issues

2008-02-07T00:19:54Z

Guillaume Lebleu: /* removed issue from 2007 */

<h1> hCard issues </h1>
{{TOC-right}}
These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documedabnted here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] and the [[hcard-issues-resolved|hCard resolved issues]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].

See other [[issues]] also.

== closed issues ==
See: [[hcard-issues-resolved]]

== resolved issues ==
See: [[hcard-issues-resolved]]

== issues ==
Please add new issues to the '''bottom''' of the list by copy and pasting the [[hcard-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

=== 2006 ===

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''There should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself.''
*#* Quite often I see "a" webpage accessible with several different URLs. Typically 1 URL is the "preferred" URL, expected to have a long lifetime. Sometimes other URLs are "convenience" URLs that may have been linked to in the past, but are expected to go away soon, which resolve to the same file (the "latest version"). Then there are "archive" URLs that show an exact copy of that webpage as it appeared some time in the past. I think we want to always use the "preferred" URL, no matter which of those URLs we happen to stumble upon first -- so the URL is not actually redundant. (How exactly is it "accessibility-damaging" for a page to link to itself? Could you explain or add a link to an explanation?) --[[User:DavidCary|DavidCary]] 17:44, 5 Apr 2007 (PDT)
*#**"''How exactly is it "accessibility-damaging" for a page to link to itself?''" - Novice user clicks on link; nothing (it appears) happens. Repeat ad infinitum, until user leaves site to do something else. [[User:AndyMabbett|Andy Mabbett]] 02:43, 6 Apr 2007 (PDT)
*#*A: ACCEPTED THEORETICAL. While I tend to agree with the accessibility guidelines/issues noted herein in theory, to make this a real world issue worthy of higher priority, we need documentation of examples in the wild where the URL of an hCard or hCalendar event is the URL of the page itself, so that we can use those examples to inform brainstorming towards a solution. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
*#** Examples in the wild where the URL of an hCard is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes] page at SXSW 2007 (1 of 1000+ bands). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCard for The Pipettes to indicate that the page itself is the URL for the hCard.
*#*** See also the proposal to use this pattern in [[representative-hcard]]
*#** Examples in the wild where the URL of an hCalendar event is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes at La Zona Rosa] page at SXSW 2007 (1 of 1000+ concerts, yes, same page as the page for The Pipettes the org). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCalendar event for The Pipettes at La Zona Rosa to indicate that the page itself is the URL for the hCalendar event.
*#** This is also an [[hreview-issues|hReview issue]] and any other microformat which has a "url" property. Examples where the URL of an (potential) hReview *item* is the URL of the page itself:
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions of potential hReview items/products with reviews on their item pages).

=== 2007 ===
* {{OpenIssue}} 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# RFC2426 'type' values cannot be localized/internationalized in hCard. In the example below, there is no solution to mark the Spanish version with a type of 'home' since the RFC2426 values are defined in English. abbr-design-pattern would suggest using abbr, but 'Casa' is not an abbreviated form of 'home', therefore the currently recommended version (below) is not valid.<pre><nowiki>

<abbr class="type" title="home">Casa</abbr> (preferido):
+1.415.555.1212

</nowiki></pre>
*#* REJECTED. TOO LITTLE INFORMATION. Please provide the precise URL to the specific statement on the accessify forum discussion that asserts that using abbr is not valid. Please also provide a precise URL to a *real world* (as opposed to an artificially constructed test case) example in the wild of an non-English hCard which attempts to specify RFC2426 type information on a "tel" property and fails to do so.
*#* REOPENED and clarified (Also removed Accessify reference pulled from [[http://microformats.org/wiki?title=accessibility&oldid=12943 original raising]]).
*#*# Though erroneously first raised on the accessibility page, this is not an accessibility issue. It is an HTML semantics issue for internationalization. <code>abbr[title]</code> should be an expanded form of <code>abbr</code> contents, in the same language.
*#*# There are real-world non-English examples in the current Mac OS 10.5 (Leopard) developer seed. This code example illustrates the point sufficiently.
*#*# Please leave the clarification as-is even if you feel you must RE-REJECT (add-on, don't revert). My original points were lost when they were taken out of context and moved here. -[[User::JamesCraig|JamesCraig]]

<div class="vevent">
* {{OpenIssue}} 2007-03-19 raised by [[User::ChristinaHope|Christina Hope]]
<div class="description">
*# ''Does Microsoft Outlook 2003 allow the use of the "role" property? I have added it to all of my hCards and it is not appearing. Am I doing something wrong?''
*#** URL? (if no URL to a demonstrative example is provided within a year of this issue being raised, it will be closed as REJECTED INSUFFICIENT INFORMATION.)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2007-03-31 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)
*#* Note also the forthcoming [http://www.euref-iag.net/ European Terrestrial Reference System 89 schema] (See also [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 on Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 Apr 2007 (PDT)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2007-04-19 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
*#How should we handle [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Old Style and New Style dates] (i.e. Julian calendar vs. Gregorian), in DoB? For instance, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], born "10 February [O.S. January 29] 1890". Should the hCard spec. specify New Style, using the [[abbr-design-pattern]] (or its successor) if necessary: <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?
</div>
</div>

===2008===

<div class="vevent">
* {{OpenIssue}} 2008-01-01 raised by [[User:AndyMabbett|Andy Mabbett]] in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011182.html microformats-discuss/2008-January/011182.html]
<div class="description">
*# The "n" optimisation rules (nickname, fn) should not apply where the fn is on part of adr or label: e.g <code><nowiki>
New York</nowiki></code>; <code><nowiki>Asia</nowiki></code>, since, in these examples, "Asia" is not a nickname, "New" is not a given-name and "York" is not a family-name. (see also [[hcard-brainstorming#Named_locations]])
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-01-09 2008- moved from vcard-suggestions
<div class="description">
*#We can't have a generic type name cause we have to localize in French. so, for us, hCard work phone number is: <nowiki><div class="tel">Travail : 0321596224</div></nowiki>. How will a bot recognize that type ? We cannot specify every types in every languages in the specification. That's why i think something like this would be better: <nowiki>Travail : 0321596224</nowiki> Please, use class and id attributes ONLY for micro formats specifications ! XML #cdata and #data are localized ! Thanks !
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-02-02 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
*# The "n" optimisation rules (nickname, fn) should not apply where the fn is also the role: e.g <code><nowiki>
Webmaster</nowiki></code>; <code><nowiki>Duty Manager</nowiki></code>, since, in these examples, "Webmaster" is not a nickname, "Duty" is not a given-name and "Manager" is not a family-name.
</div>
</div>

== template ==

{{issues-format}}

== related pages ==
{{hcard-related-pages}}

hcard-issues

2008-02-07T00:18:45Z

Guillaume Lebleu: /* 2007 */

<h1> hCard issues </h1>
{{TOC-right}}
These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documedabnted here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] and the [[hcard-issues-resolved|hCard resolved issues]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].

See other [[issues]] also.

== closed issues ==
See: [[hcard-issues-resolved]]

== resolved issues ==
See: [[hcard-issues-resolved]]

== issues ==
Please add new issues to the '''bottom''' of the list by copy and pasting the [[hcard-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

=== 2006 ===

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''There should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself.''
*#* Quite often I see "a" webpage accessible with several different URLs. Typically 1 URL is the "preferred" URL, expected to have a long lifetime. Sometimes other URLs are "convenience" URLs that may have been linked to in the past, but are expected to go away soon, which resolve to the same file (the "latest version"). Then there are "archive" URLs that show an exact copy of that webpage as it appeared some time in the past. I think we want to always use the "preferred" URL, no matter which of those URLs we happen to stumble upon first -- so the URL is not actually redundant. (How exactly is it "accessibility-damaging" for a page to link to itself? Could you explain or add a link to an explanation?) --[[User:DavidCary|DavidCary]] 17:44, 5 Apr 2007 (PDT)
*#**"''How exactly is it "accessibility-damaging" for a page to link to itself?''" - Novice user clicks on link; nothing (it appears) happens. Repeat ad infinitum, until user leaves site to do something else. [[User:AndyMabbett|Andy Mabbett]] 02:43, 6 Apr 2007 (PDT)
*#*A: ACCEPTED THEORETICAL. While I tend to agree with the accessibility guidelines/issues noted herein in theory, to make this a real world issue worthy of higher priority, we need documentation of examples in the wild where the URL of an hCard or hCalendar event is the URL of the page itself, so that we can use those examples to inform brainstorming towards a solution. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
*#** Examples in the wild where the URL of an hCard is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes] page at SXSW 2007 (1 of 1000+ bands). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCard for The Pipettes to indicate that the page itself is the URL for the hCard.
*#*** See also the proposal to use this pattern in [[representative-hcard]]
*#** Examples in the wild where the URL of an hCalendar event is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes at La Zona Rosa] page at SXSW 2007 (1 of 1000+ concerts, yes, same page as the page for The Pipettes the org). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCalendar event for The Pipettes at La Zona Rosa to indicate that the page itself is the URL for the hCalendar event.
*#** This is also an [[hreview-issues|hReview issue]] and any other microformat which has a "url" property. Examples where the URL of an (potential) hReview *item* is the URL of the page itself:
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions of potential hReview items/products with reviews on their item pages).

=== 2007 ===
* {{OpenIssue}} 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# RFC2426 'type' values cannot be localized/internationalized in hCard. In the example below, there is no solution to mark the Spanish version with a type of 'home' since the RFC2426 values are defined in English. abbr-design-pattern would suggest using abbr, but 'Casa' is not an abbreviated form of 'home', therefore the currently recommended version (below) is not valid.<pre><nowiki>

<abbr class="type" title="home">Casa</abbr> (preferido):
+1.415.555.1212

</nowiki></pre>
*#* REJECTED. TOO LITTLE INFORMATION. Please provide the precise URL to the specific statement on the accessify forum discussion that asserts that using abbr is not valid. Please also provide a precise URL to a *real world* (as opposed to an artificially constructed test case) example in the wild of an non-English hCard which attempts to specify RFC2426 type information on a "tel" property and fails to do so.
*#* REOPENED and clarified (Also removed Accessify reference pulled from [[http://microformats.org/wiki?title=accessibility&oldid=12943 original raising]]).
*#*# Though erroneously first raised on the accessibility page, this is not an accessibility issue. It is an HTML semantics issue for internationalization. <code>abbr[title]</code> should be an expanded form of <code>abbr</code> contents, in the same language.
*#*# There are real-world non-English examples in the current Mac OS 10.5 (Leopard) developer seed. This code example illustrates the point sufficiently.
*#*# Please leave the clarification as-is even if you feel you must RE-REJECT (add-on, don't revert). My original points were lost when they were taken out of context and moved here. -[[User::JamesCraig|JamesCraig]]

<div class="vevent">
* {{OpenIssue}} 2007-03-19 raised by [[User::ChristinaHope|Christina Hope]]
<div class="description">
*# ''Does Microsoft Outlook 2003 allow the use of the "role" property? I have added it to all of my hCards and it is not appearing. Am I doing something wrong?''
*#** URL? (if no URL to a demonstrative example is provided within a year of this issue being raised, it will be closed as REJECTED INSUFFICIENT INFORMATION.)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2007-03-31 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)
*#* Note also the forthcoming [http://www.euref-iag.net/ European Terrestrial Reference System 89 schema] (See also [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 on Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 Apr 2007 (PDT)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2007-04-19 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
*#How should we handle [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Old Style and New Style dates] (i.e. Julian calendar vs. Gregorian), in DoB? For instance, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], born "10 February [O.S. January 29] 1890". Should the hCard spec. specify New Style, using the [[abbr-design-pattern]] (or its successor) if necessary: <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-MM-DD raised by [[User:Guillaume Lebleu| Guillaume Lebleu]]
<div class="description">
*# It seems to me that FN has been reused beyond its original vCard scope of person names, to cover any name. This led to the fn/title debate, but it seems some implementors are confused between following the vCard semantics (FN only for person names) or the hCard ones (FN for any name). See. http://cinematreasures.org/theater/365/, which uses an empty FN, resulting in their vCard not being detected by Operator, only the address.
</div>
</div>

===2008===

<div class="vevent">
* {{OpenIssue}} 2008-01-01 raised by [[User:AndyMabbett|Andy Mabbett]] in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011182.html microformats-discuss/2008-January/011182.html]
<div class="description">
*# The "n" optimisation rules (nickname, fn) should not apply where the fn is on part of adr or label: e.g <code><nowiki>
New York</nowiki></code>; <code><nowiki>Asia</nowiki></code>, since, in these examples, "Asia" is not a nickname, "New" is not a given-name and "York" is not a family-name. (see also [[hcard-brainstorming#Named_locations]])
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-01-09 2008- moved from vcard-suggestions
<div class="description">
*#We can't have a generic type name cause we have to localize in French. so, for us, hCard work phone number is: <nowiki><div class="tel">Travail : 0321596224</div></nowiki>. How will a bot recognize that type ? We cannot specify every types in every languages in the specification. That's why i think something like this would be better: <nowiki>Travail : 0321596224</nowiki> Please, use class and id attributes ONLY for micro formats specifications ! XML #cdata and #data are localized ! Thanks !
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-02-02 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
*# The "n" optimisation rules (nickname, fn) should not apply where the fn is also the role: e.g <code><nowiki>
Webmaster</nowiki></code>; <code><nowiki>Duty Manager</nowiki></code>, since, in these examples, "Webmaster" is not a nickname, "Duty" is not a given-name and "Manager" is not a family-name.
</div>
</div>

== template ==

{{issues-format}}

== related pages ==
{{hcard-related-pages}}

hcalendar-issues

2008-01-17T16:53:20Z

Guillaume Lebleu: /* 2008 */

<h1>hCalendar issues</h1>

These are externally raised issues about [[hcalendar|hCalendar]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

'''IMPORTANT''': Please read the [[hcalendar-faq|hCalendar FAQ]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

See related [[hcard-issues]].

__TOC__

== Closed Issues ==
Resolved issues that have no further actions to take. These will likely be moved to a separate page like [[hcalendar-issues-closed]].

* 2006-01-04 raised by [[User:CGranade|CGranade]]
*# ''Interactions with strong namespacing. So far, it seems that hCalendar cannot be embedded into non-XHTML schemas that are also strongly namespaced (e.g.: RDF, Atom) without a resultant validation error, as the <code>class</code> attribute is ''not'' portable across schemas.''
*#* REJECTED. The class attribute is used on XHTML elements, which are XML, which can be embedded in any other XML. The issue as raised doesn't make sense.

* 2005-02-18 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
*# ''There is no way for some reading the markup to tell if a class name is the name of an attribute or simply the name of a class used for styling.''
*#* REJECTED (strawman, poor assumption). There is no need to differentiate in the general case. In the specific case, a vocabulary is defined within a context.
*# ''As a result of the above, user agents would not be able to reliably allow users to access extension properties such as "x-mozilla-alarm-default-length" (which is an actual extension used in Sunbird).''
*#* REJECTED (out of scope). Extension properties are outside the current scope of hCalendar.
*# ''The use of <abbr> for dates is incorrect. "August 5th, 2004" is not the abbreviation of 2004-09-05. In fact, the opposite is closer to the truth.''
*#* REJECTED (false statement). This is simply a false statement. See this article for an explanation of this use of <abbr>: [http://tantek.com/log/2005/01.html#d26t0100 Human vs. ISO8601 dates problem solved]
*# ''You have to create a complex set of rules for all possible uses of legacy markup within which can easily be implemented incorrectly.''
*#* REJECTED (false statements, strawman). There is no legacy markup. There is no need to create rules for all possible uses of legacy markup. There is no need to create a complex set of rules.
*# ''There are styling and tooltip issues that are unresolved.''
*#* REJECTED (empty statements). See the [[hcalendar-faq|hCalendar FAQ]] for answers to specific styling and tooltip questions. Otherwise, please raise specific issues here with clear valid examples.
*# ''hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.''
*#* REJECTED (empty statements, invalid comparator). Please state specific examples which show the perceived complexity. The comparison "more complicated" requires two items, no second item was provided.

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items.
* 2006-02-17 raised by [[User:Mark Mansour|Mark Mansour]] - notes are summarized [[hcalendar-irc-meetup-20060225|here]]
*# Should vcalendar be a class? Section 4.4 of RFC2445 says: "The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be sequentially grouped together." Also the vcalendar class would allow properties on the calendar itself such as METHOD and CALSCALE (I don't think VERSION and PRODID are particularly relevant).
*#* ACCEPTED SPECUPDATE/FAQ. Is this a case of fixing something that isn't broken? Note that "iCalendar object" != "vcalendar". This is a bit confusing so read RFC 2445 carefully in that regard. In addition, the [[hcalendar|hCalendar]] spec should say *precisely* how to generate VCALENDAR properties in their absence.
*# How are axis and headers going to be handled?
*#* ACCEPTED. This is documented in [[hcalendar-brainstorming]] but MUST be moved to [[hcalendar|hCalendar]] proper as the editors and implementers have all agreed on it (months ago). Add this as a [[to-do]] for Tantek.
*# There has been talk that table axis and headers should be used to capture calendar information in a more compact format, but no example are available. Does anyone have examples or should we try to invent some?
*#* REJECTED. Please RTFM. Searching the [[hcalendar|hCalendar]] spec for *either* "axis" or "headers" would have found the following example in the wild: [http://we05.com/ Web Essentials 05] has marked up their [http://we05.com/program.cfm program schedule table with hCalendar], using the 'axis' and 'headers' attributes.
*# Should embeded components be allowed? [[RyanKing]] has already noted that vJournal overlaps blog-posts (although not yet accepted), but should the components to-do, free/busy, timezone, alarms be allowed? They all considered as just as relevant by the ical spec as events are (my interpretation).
*#* ACCEPTED SPECUPDATE/FAQ. Another [[to-do]] for Tantek. Explicitly specify which additional iCalendar objects (in addition to VEVENT) are permitted in hCalendar. Current additional candidates: VTODO (many examples of this info on the web), VFREEBUSY (already at least one site publishing this info), VALARM (maybe, seems harmless enough, but without a compelling real world use case we should probably omit it). Currently dropping: VTIMEZONE (terrible construct), VJOURNAL (obsoleted by [[hatom|hAtom]]).
*# Validation of the hCalendar tests. The hCalendar tests have been available for a while now, but only Brian Suda and I have made contributions to their content. Does anyone else have thoughts and should we try to make these the beginning of 'official' hCalendar tests?
*#* ACCEPT PARTIAL. We probably need an hCalendar ''validator'' before we can declare any set of tests to be official.
*# The use of fragments is unclear. Fragment interpretation seems to be agent dependant. Fragments usually denote a heading or marker, like a goto statement for HTML. Unfortunately it may jump in the middle of elements (rather to the beginning of an element). How should this be handled. i.e.
<pre>
<a name="myfrag">heading</a>
<div class="vevent">
<div class="description">A nice event</div>
<abbr class="dtstart" title="2005-10-05">October 5</abbr>
</div>
</pre>
*#* ACCEPTED. We should clarify to converters how to interpret a fragement id. The interpretations are all consistent. It points to the element that is to be converted. If that element is empty then so is the conversion. There is no issue here other than a need for more documentation.
* 2006-02-01 raised by [[RyanKing]]
*# ''Issue 1: Given that now, or soon will have hAtom, should we disallow vJournal, so that we don't have 2 blog-post formats?''
*#* ACCEPTED. Yes, we should expliclty DROP "vjournal" from [[hcalendar|hCalendar]].
* 2006-01-04 raised by [[User:CGranade|CGranade]]
*# ''...''
*# ''All examples in XHTML. XHTML should not be the only host to microformats, and thus it should not be the only example host language. Rather, examples in Atom, RSS, RDF, etc. should also be provided.''
*#* ACCEPTED. This is definitely something to be added to *-examples pages for each microformat.
* 2005-10-14 raised by [[User:MarkoMrdjenovic|MarkoMrdjenovic]]
*# ''UID has to be present in iCal events if they want to be used in Microsoft Outlook. [Suggestion:] it should probably be added to the vevent tag as html attribute id. There is also the problem of converters - x2v has UID commented out. [http://www.ietf.org/rfc/rfc2445.txt RFC] recommends use of addr format for uids which is problematic in html id (does not validate). [[User:HenriBergius|HenriBergius]] pointed out some calendaring software crashes when @ is in the UID, so some other form of identification should be used - along the lines of dtstart-dtend-hash(title,summary)-sample-org''.
*#* ACCEPTED-PARTIAL. Yes, it appears RFC2445 requires UID. However, typical mentions of events by web authors do not provide anything equivalent to a UID, nor should we require authors to do so. Thus we must come up with an algorithm for implied UID, similar to some of the other properties. We REJECT the use of the html 'id' attributre as a substitute for UID as they are of different scopes and thus such a translation will likely be problematic. As part of this algorithm, we MUST disallow "@" signs since the issue points out that such UIDs crash some calendaring software.
*# ''DTSTAMP also has to be present in iCal event for Microsoft Outlook. I think DTSTAMP should be user visible information so implementation with class="dtstamp" is fine. x2v already supports it so it should just be added to the standard and examples. The converters might also think of a way to force (create) dtstamp if it's not present.'' [Suggestion:] why not set DTSTAMP to DTSTART if not explicitly defined? -- [[DimitriGlazkov]]
*#* ACCEPTED. We should come up with a way to encourage/synthesize/imply DTSTAMP property values.
*# ''Here is an example from Midgard CMS (which will be easy to change according to bergie on irc):''
*#* For more discussion of this, please see [http://microformats.org/wiki/hcalendar-brainstorming#UID_handling hCalendar brainstorming: UID handling]
<pre><nowiki>
<li class="vevent" id="2678c3f94af4a49f9ccbb69b92a82aba-midgardGuid">
<abbr class="dtstart" title="2005-10-20T14:34:45Z">Torstai 20. Lokakuu 17:34</abbr> -
<abbr class="dtend" title="2005-10-20T15:33:56Z">18:33</abbr>
<a class="url" href="/bergie/another-calendar/82457028ba83407451edd8aaeaa40622.html">
From the other cal
</a>
<abbr class="dtstamp" title="2005-10-14T12:16:45Z">Torstai 14. Lokakuu 12:16</abbr>
</li></nowiki></pre>
* 2005-09-29 raised by RyanKing
*# ''How does one use ATTENDEE?''
*#* ACCEPTED. Another [[to-do]] for Tantek - document how to use ATTENDEE with [[hcard|hCard]].

* 2005-06-21 raised by Hixie
*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCalendars must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?
*#* ACCEPTED. Another [[to-do]] for Tantek, write-up [[hcalendar-parsing]] that documents precisely how user agents are to parse [[hcalendar|hCalendar]] markup.
* 2005-02-22 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003124.html on the whatwg list]:
*# ''There is no copyright statement and no patent statement.''
*#* ACCEPTED. I have updated [[hcalendar]] (and [[hcard]], and all other MicroFormats) with a standard copyright statement and patent statement.

* 2005-02-18 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
*# ''...''
*# ''...''
*# ''...''
*# ''...''
*# ''...''
*# ''...''
*# ''I dislike the entire system of using class names as markup. Class names should be reserved for user-defined semantics.''
*#* ACCEPT-PARTIAL. When specific elements are available, they should be used instead of class names, but even then class names work well to "subclass" specific elements. This is thoroughly discussed in the essay [http://tantek.com/log/2002/12.html#L20021216 A Touch of Class]. And yes, class names can and should be used for user-defined semantics. [[hcalendar|hCalendar]] is one such user, and it is reasonable for users to use each others class names.
*#* ''Would it be more in the spirit of HTML to define these classes in a [http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.3 metadata profile], so that "User agents may... perform some activity based on known conventions for that profile"? Should this be a part of [[microformats]] specifications in general? (If not, why not?)''
*#** ACCEPTED. Yes, all [[microformats]] that introduce new classnames SHOULD include an [http://gmpg.org/xmdp/ XMDP] profile (which itself is a microformat for defining HTML metadata profiles) that defines those classnames.
*#*** ''Ok, but in order to refer to a profile, it needs a URI. Tantek writes in [http://microformats.org/discuss/mail/microformats-discuss/2005-July/000407.html a message of Jul 21] "This is precisely the reason that GMPG was founded and created, to provide permanent URLs/homes for microformat profiles." How does one cause GMPG to issue a profile URL?''
*#**** ACCEPTED. See [[profile-uris]]; this is moving from Tantek's [[to-do]] list, to both provide profiles and URLs (probably at gmpg.org) for those profiles for hCalendar etc.

== Issues ==
Please add new issues to the '''bottom''' of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

=== 2005 ===

* 2005-07-11 raised by Kragen
*# ''The specification of class="url" as <a href="..."> should be a "should", not a "must". Other ways of referencing the event URL, such as <iframe src="..."> and <embed src="...">, shoul be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about [[xfolk|xFolk]].''
*#* REJECTED. Lack of use case. We should not add additional "ways of referencing the event URL" unless you can show a concrete real world example on the Web which requires it.

* 2005-07-21 raised by Neil Jensen
*# ''should we create a vfreebusy class for HTML representations of freebusy data? Discussion [http://microformats.org/wiki/hcalendar-brainstorming#Free.2FBusy_information on hCalendar brainstorming]. Additional background: [http://www.ifreebusy.com/cyclical/blog/calendar/3.html here].''

* 2005-07-27 raised by Paolo Massa
*# ''I tried to add a hcalendar event in my blog but it rendered orribly. The problem was I already have a 'class="summary' in my normal HTML (it is the title of the posts) and my CSS displays it bigger and bold. In this way the summary of the event was as big as the titles of the posts, destroying readability. The problem is Overloading of class attributes, it might be the case that a blogger already use, for example, class="summary" for different purposes. What can be a solution? Providing in every microformat wiki page a CSS file that users can download and insert in their blog as additional CSS. This CSS file will "shield" attribute "inside" microformats from being interpreted as "normal" attributes. For example for the hCalendar microformats the relative CSS could be something like:

.vevent .summary {

//remove all the previously set properties, for example:

text-decoration: none;

font-size: 100%;

...

}

Since the hCalendar microformat is the following,



<a class="url" href="http://www.web2con.com/">

Web 2.0 Conference:

...

I hope to have been clear but I'm not so sure ;-)''

=== 2006 ===

<div class="vevent">
* {{OpenIssue}} 2006-03-07 raised by [[User:Ragdoll|Justin McDowell]]
<div class="description">
*# I'd love to see a Property List, similar to what is seen in the hCard spec, that lists all the available properties and sub-properties in a nice, compact list. This saves a lot of time and is really useful for quickly and easily getting acquainted with the possibilities of vCalendar.
*#* See [[hcalendar-cheatsheet]] . [[User:Leikam|Michael Leikam]] 2007-01-29
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2006-04-10 raised by [[User:ScottReynen|Scott Reynen]]
<div class="description">
*# When someone looks at the [[hcalendar|hCalendar]] pages, one sees no collection of real-world publishing of event data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the [[process]] nor the hCalendar pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2006-04-13 raised by Tantek
<div class="description">
*# Need to add a section on "Property Exceptions" like that in [[hcard|hCard]] to document how to publish / handle the '''METHOD''' property and potentially others. I.e. typically publishers may omit the METHOD property, however, converters whose function is to convert [[hcalendar|hCalendar]] to iCalendar for consumption/subscription by a calendar aggregator, should probably insert a default '''METHOD:PUBLISH''' on the '''VCALENDAR''' object in the resultant .ics stream.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2006-08-14 raised by [[User:Elias|Elias Sinderson]]
<div class="description">
*# Although ISO 8601 allows both basic (sans delimiters) and extended formats, the extended format (where hyphens and colons are explicitly added) is broadly preferred for the web. While RFC 2445 specifies that the basic form be used in in iCalendar date / time fields, the W3C has published a technical [http://www.w3.org/TR/NOTE-datetime note] (submitted by Reuters), which recommends that the extended (delimited) format be used, and the [http://www.w3.org/TR/html401/types.html#h-6.11 HTML 4.0 spec] uses the extended format. Further, RFC 3339 defines a ISO 8601 profile for dates and time representations on the internet that future specs SHOULD use; recommending a fully delimited representation (see sec. 5.6). Lastly, it should be noted that the [http://www.w3.org/TR/xmlschema-2/#date xsd:date] and [http://www.w3.org/TR/xmlschema-2/#dateTime xsd:dateTime] types are specified as being the ISO 8601 extended format. So, given that hCalendar is based on iCalendar, it is understandable that it allows both formats, however this is clearly a case in which it would be very reasonable to require users to upconvert the format into the least ambiguous and most easily parsed/ validated representation. Think of the children.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2006-09-22 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
*# How are Julian dates to be displayed? So far as I am aware, ISO8601 has no facility for marking up Julian dates, so should the form <pre><nowiki><abbr class="dtstart" title="[Gregorian date]">[Julian date]</abbr> </nowiki></pre> be used? If so, that should be indicated, via an example.
</div>
</div>

=== 2007 ===

<div class="vevent">
* {{OpenIssue}} 2007-01-07 raised by [[User:Webf|Webf]]
<div class="description">
*# ''Looking for a mechanism for specifying a dtstart without using <nowiki><abbr></nowiki>. Would be used where there are a number of events (as in the [http://www.webfeet.org/events.html Webfeet events lists]) where you do not want to have the visible date repeated''
*#* <code>abbr</code> is the correct - and only - element to use, unless you wish to display the raw ISO-formatted date-time to the user. Use it with the [[include-pattern]], thus:

<code>
<pre>
<nowiki>
<dt id="D20070120">
<abbr class="dtstart" title="20070120">
Saturday, 20 January 2007
</abbr>
</dt>
<dd>

<object class="include" data="#D20070120"></object>
[Details of first event]



<object class="include" data="#D20070120"></object>
[Details of second event]

</dd>
</nowiki>
</pre>
</code>

:but please note that you should validate your HTML - it has over 3,000 errors! The high number of hCalendar microformats (>500) is causing parsers such as Firefox's Tails and Operator to respond very slowly. You should use CSS, not non-breaking spaces and multiple line-breaks, to layout your page - this will reduce it's size and enable parsers to work more quickly. You will need to style <code>object .include</code> to <code>display:none</code> [[User:AndyMabbett|Andy Mabbett]] 04:10, 16 Jan 2007 (PST)

:Thanks Andy!
:* This use of <code>object</code> is a proposal at this stage? It does not seem to be mentioned in the [[hCalendar|hCalendar]] page and only marked 'under consideration' in [[include-pattern#Specifications_Using|Include Pattern]]
:* Re: '>500 entries', I would think that User Agents ''should'' be able to deal with this. The linked page displays a collection of events (not all pages will have so many :-) however I would expect a User Agent to worry mainly about the events visible on the screen (really, a ''small'' part of the whole page).
:** Brainstorming a little, I would hope that the UA could track an event I've inserted ino my calendar and notice any changes, such as the event being postponed/cancelled, pick up this info and update my calendar. Worth thinking what implications this might bring to the markup.
:** I'm thinking though that the primary effort with a UA would be making sure the 99.99% pages which ''do not'' include hCalendar markup are not slowed down!
:* Re: <code>abbr</code> as the ''only'' way, I can see <code>abbr</code> used within the [[hCalendar|hCalendar]] page and, yes, it looks a exceptionally neat way of rolling up some markup but I don't see it defined as a mandatory for marking up an event.
:** Am I missing some rationale? Why is <code>abbr</code> the ''only'' option?
:** Should the spec be written up more formally? should hCalendar be more relaxed? My take is that <code>abbr</code> is OK but it would be wrong for it to be mandatory. Think that screen readers may be reading the expanded content (as with <code><nowiki><abbr title="Web Accessibility Initiative">WAI</abbr></nowiki></code>). The underlying issue is that [[hCalendar|hCalendar]] seems to want <code>abbr</code> to disambiguate a displayed date and this is not really the same as an abbreviation. UA's should be liberal when looking for a <code>class="dtstart"</code>, after all they do know that they are within an event markup as they have met the <code>class="vevent"</code>....
:*Feel free to move the above thoughts to a brainstorming area. I might come back to the other points later - but maybe better in a talk page. :-) [[User:Webf|Webf]] 13:23, 21 Jan 2007 (PST)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2007-01-20 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
:: Where <code>DTEND</code> is a date, and not a date-time, it is required to be the day after the end of the event, thus: <code><nowiki>
<abbr class="dtend" title="2007-04-30">29 April 2007</abbr></nowiki></code>. However, "29 April 2007" is '''''not''''' an abbreviation of 2007-04-30; it is an abbreviation of 2007-04-29. The markup as shown is semantically incorrect and likely to cause problems for users and user-agents which read the title attribute, and not the text value, of the <code>abbr</code> element.
::[[User:Webf2|Webf2]] 23:23, 11 May 2007 (PDT)
::*The ISO date 2007-04-30 is directly equivalent to 2007-04-30 00:00:00, which is why it's used as the end time of an event occuring on 2007-04-29. In this fuller context then you can view it as an abbreviation of 'the end of 29 April 2007'. Authors uncomfortable with this could use <nowiki><abbr class="dtend" title="2007-04-29 23:59:59">29 April 2007</abbr></nowiki>, or be more specific with their times.
:::[[User:CiaranMc|Ciaran McNulty]] 09:21, 12 May 2007 [GMT]
:::*The ISO standard has 2007-04-29 24:00:00 expressly to mark the end of the day 2007-04-29 rather than the start of the day 2007-04-30. This seems far preferable to 23:59:59. [[User:Matthew|Matthew]] 15:22, 17 Jul 2007 (PDT)

::* This certainly risks confusion. The abbr title includes different information than the content; different when read by a 'normal' user who does not know about the exclusive-end-date.

:::* The trouble is going to be with dates (rather than date-times). User expectation is different if you are talking about "3 o'clock", which really is a point-in-time, and "29th April", something lasting 24 hours. No problem saying an end time is 'exclusive', but an end-date can be either and is typically inclusive.
:::* Using a more precise <code>dtend</code> is just a workround, you might not really want to say to the second when an event ends (as in 2007-04-29 23:59:59). You might easily want to say it runs from the Wednesday to Friday without committing to precise times - or that the event is sometime on that Friday but you don't know when.

::: Possible options could be:
:::* Include a note in the standard that contradictory markup such as
:::: <code><nowiki><abbr class="dtend" title="2007-04-30">29 April 2007</abbr></nowiki></code>
:::: is bad practice and should be avoided
:::* Make a break with the ical usage that end dates are exclusive.
:::* Make the meaning clear:
:::: <code><nowiki><abbr class="dtend" title="value=date:value=inclusive:2007-04-29">29 April 2007</abbr></nowiki></code>
:::: <code><nowiki><abbr class="dtend" title="value=exclusive:2007-04-30">29 April 2007</abbr></nowiki></code>
:::: or maybe
:::: <code><nowiki><abbr class="dtend;value=date:value=inclusive" title="2007-04-29">29 April 2007</abbr></nowiki></code>

::: [[User:Webf2|Webf2]] 00:25, 13 May 2007 (PDT)
*# Here is the first issue I have.
*# Here is the second issue I have.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2007-05-12 raised by Anon
<div class="description">
*# A pertinent point from the [http://microformats.org/wiki?title=hcalendar-issues&oldid=16115 22 Feb 2007 version] of hcalendar issues. Worth keeping and addressing.
</div>
</div>

=== 2008 ===

<div class="vevent">
* {{OpenIssue}} 2008-01-16 raised by [[User:AndyMabbett|Andy Mabbett]]
<div class="description">
*# Lack of method for marking up vague dates and eras; see [[history-examples#The_Problem|vague-date examples]].
</div>
</div>

<div class="vevent">
* {{OpenIssue}} 2008-01-17 raised by [[User:Guillaume Lebleu|Guillaume]]
<div class="description">
*# In some instances, see [http://biz.yahoo.com/c/e.html|Yahoo Economic Calendar], the content in dtstart is split into two td (same issue for summary), which requires to either tag the date as dtstart or the time as dstart. The reason is that due to the structure of HTML tables, it is not possible to mark up each part of the dtstart as value and wrap them all in an element of class dstart.
</div>
</div>

== Template ==

{{issues-format}}

== Related Pages ==
{{hcalendar-related-pages}}

vcard-suggestions

2008-01-08T20:17:32Z

Guillaume Lebleu: /* Suggestions for SMS TEL TYPE */

<h1> vCard suggestions </h1>

As a result of experience using [[hcard|hCard]] to markup people, organizations, and contact information in general on [[hcard-examples-in-wild|real world websites]], we have discovered a few aspects of RFC 2426 vCard that could be improved. Thus we are documenting suggestions for improving vCard here as we find them, organized by RFC 2426 section number for improvements to current properties, and a "new" section for new properties.

; Authors
:[[User:Tantek|Tantek Çelik]]
:[[User:AndyMabbett|Andy Mabbett]]

== Suggestions for Existing Properties ==

Suggestions for improvement could include new features and other such more major changes to the specification, organized under headings that reflect RFC 2426 vCard section numbers and heading. For documentation of errors, corrections, errata for vCard, please see [[vcard-errata]].

=== 3.3.1 TEL Type Definition ===

* The "type" for "TEL" lacks a "textphone" option (for the devices used by, e.g., people who are deaf or have speech difficulties. Example: [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)]. It may be good to consider adding a "textphone" value to the "type" for "TEL".
** +0 Tantek: I think a rethinking of the taxonomy of TEL types is merited, but I am uncertain whether it is worth growing the existing limited taxonomy or instead permitting user defined TEL types and thus allowing for natural evolution of a folksonomy of TEL types.
** +1 [[User:AndyMabbett|Andy Mabbett]]: There are a limited number of types. Note also the cell vs. mobile issue.
* The "type" for "TEL" lacks a "freephone" option. It may be good to consider adding a "freephone" value to the "type" for "TEL". Usually freephone numbers are not accessible from outside the country so it could help parsers with something?
* The "type" for "TEL" lacks an "SMS short code" option. (Raised in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011292.html e-mail, 2008-01-08 by Michael Smethurst])
** Seems like 'sms' TEL TYPE is a viable implementation option --[[User:Guillaume Lebleu|Guillaume]] 12:17, 8 Jan 2008 (PST).
* FYI. Some existing Personal Information Manager software practices:
** Mac OS X address book allows custom labels for TEL but not custom TEL TYPE per se, although for the user a custom TEL label just looks like a TEL TYPE
** Microsoft Outlook does not allow custom TEL TYPE values. Also, Microsoft Outlook has a "Company" telephone type, but unfortunately it isn't mapped to anything in vCard i.e. if you export a contact with a company tel, it is lost.
** Windows Mobile 6 displays SMS as a service that is only available if the telephone type is 'mobile'.
** Thunderbird 2 (Mac) does not allow custom TEL TYPE values.

Note: it might be a good idea to look at the [http://tools.ietf.org/html/draft-ietf-iptel-tel-reg-04 proposed registry for "tel:" URI parameters]; especially the [http://tools.ietf.org/html/rfc3966 "phone-context" URI parameter], since it tries to solve a similar problem. (per [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011295.html e-mail, 2008-01-08]).

=== 3.3.2 EMAIL Type Definition ===

* The "type" for "EMAIL" lacks distinction for various types of email, e.g. '''work''' or '''home'''.
* The "type" for "EMAIL" lacks dinstinction for give an alternative to the e-mail like a contact form.

=== 3.3.3 Suggestion for Types Definition ===

We can't have a generic type name cause we have to localize in french. so, for us, hCard work phone number is :
<nowiki><div class="tel">
Travail :
0321596224
</div></nowiki>

How will a bot recognize that type ? We cannot specify every types in every languages in the specification. That's why i think something like this would be better :
<nowiki>Travail : 0321596224</nowiki>

Please, use class and id attributes ONLY for micro formats specifications ! XML #cdata and #data are localized ! Thanks !

== Suggestions for New Properties ==
===Gender===
*There is no Card property for gender. A workaround: add the tag/category "male", "female", etc. See also [[hcard-faq#How_is_gender_represented|earlier discussion]] and [[genealogy-brainstorming#Gender]].
** -1 Tantek: I think tags/categories are good enough for now.
** +1 [[User:AndyMabbett|Andy Mabbett]]:Tags are often not appropriate, as per the cited discussion.

====Gender evidence====
See [[gender-examples]].

* Social network sites (see [[profile-examples]]) typically publish the gender of the individual. Please add such sites with specific URLs to the site, their editing UI, and their list of gender values to [[gender-examples#sites_and_services]].

* Many pages publish implicit gender information, not easily machine parsable - using names (Andrew, Andrea), titles (Mr, Mrs, Miss), relationships (husband, brother), pronouns (he, she), etc. Please add such pages with specific URLs and quotes of the explicit information, and the implied genders to the [[gender-examples#examples|gender examples]] page.

See also [[genealogy-brainstorming]].

===Deceased===

*See [[hcard-date-of-death]]

====Date of Death evidence====

*See [[hcard-date-of-death]]

===Instant Messaging===
*See [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770].

===Subject differentiator===
The use of "fn" and "fn org" differentiate between hCards for people and for other entities, but we perhaps need some further differentiator, between, say, organisations and venues (including buildings, governmental divisions, waypoints, etc.) at a level of granularity to be determined. [[User:AndyMabbett|Andy Mabbett]] 14:30, 11 Jul 2007 (PDT)

===Elevation===
*See [[geo-extension-elevation]]

===Global Location Number===
Global Location Number (GLN) - generally used in electronic commerce transactions [http://en.wikipedia.org/wiki/Global_Location_Number]. [[User:AndyMabbett|Andy Mabbett]] 06:43, 31 Aug 2007 (PDT)

===Initials===
For people, whose given-name is not stated (e.g. "A. N. Other"); to allow mark-up like:

<pre><nowiki>


A. N.
Other


</nowiki></pre>

===Alternative dates===

For historic figures, where no birth and/ or death dates are known a "'''flourished'''" date, or "'''flourished from'''"+"'''flourished to'''" pair, would be useful.

In genealogy, some people have no recorded birth date, but their "'''baptised'''" date is known.

===Continent===
<code>adr</code> should have an optional <code>continent</code> child-property.

== Suggestions for handling encodings ==
The vCard standard specifies that US-ASCII is assumed to be the encoding in the absence of a MIME content type header or a CHARSET parameter that indicates otherwise. This was an unfortunate choice. vCard .vcf files stored on a local filesystem do not contain a MIME header and the only way to reliably use an encoding other than ASCII is to tag each field with the "CHARSET=" label. This makes the vCard stream more complicated than necessary. This could be simplified by a revision of the standard that specifies UTF-8 as the default encoding. This could work safely with existing vCard .vcf files, which do not contain a MIME content header. The first vCard VERSION field would be the same encoded as either ASCII or UTF-8, so readers could easily determine which encoding to default to.

Furthermore, those creating vCard readers should be encouraged to support vCard .vcf files that begin with a UTF-8 BOM sequence. If the first three bytes of the file are 0xEF 0xBB 0xBF, the text file is UTF-8 encoded, and the vCard reader should assume UTF-8 is the default. Unfortunately many readers today fail to recognize the UTF-8 BOM and view the file as a corrupt vCard.

==Suggestions made elsewhere==

===WebDAV===

[http://www.ietf.org/internet-drafts/draft-daboo-carddav-02.txt vCard Extensions to WebDAV (CardDAV)]
<blockquote>defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. This document defines the "addressbook-access" feature of CardDAV.</blockquote>

===XEP-0154: User Profile===

[http://www.xmpp.org/extensions/xep-0154.html XEP-0154: User Profile] specifies how to represent and manage profile data about IM users and other [http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol Extensible Messaging and Presence Protocol] (XMPP) entities using the XMPP Data Forms extension. It has a far greater number of properties than vCard, but reinvents and re-names some of the latter's properties.

==Note==
On 2006-11-24, Paul Hoffman of the [http://www.imc.org/ Internet Mail Consortium], responsible for the development and promotion the vCard standard, wrote in response to an e-mail from [[User:AndyMabbett|Andy Mabbett]] informing him of this web page:
<blockquote>
There has been almost no interest in revising the vCard standard. This is due to lack of momentum, not the lack of good suggestions.
</blockquote>

However, see [[events/2007-09-18-calconnect-vcard-workshop]] for an event with vCard modification on the agenda.

== See Also ==

* [[vcard-errata|vCard errata]]
* [[vcard-implementations]]
* [[hcard|hCard]]
* [[hcard-brainstorming#Post_vCard_additions]]
* [http://www.imc.org/imc-vcard/ vCard mailing list] - a place to raise these issues, and where similar issues can be found.
* [[events/2007-09-18-calconnect-vcard-workshop]]

vcard-suggestions

2008-01-08T18:16:16Z

Guillaume Lebleu: /* 3.3.1 TEL Type Definition - Existing PIM software practices */

<h1> vCard suggestions </h1>

As a result of experience using [[hcard|hCard]] to markup people, organizations, and contact information in general on [[hcard-examples-in-wild|real world websites]], we have discovered a few aspects of RFC 2426 vCard that could be improved. Thus we are documenting suggestions for improving vCard here as we find them, organized by RFC 2426 section number for improvements to current properties, and a "new" section for new properties.

; Authors
:[[User:Tantek|Tantek Çelik]]
:[[User:AndyMabbett|Andy Mabbett]]

== Suggestions for Existing Properties ==

Suggestions for improvement could include new features and other such more major changes to the specification, organized under headings that reflect RFC 2426 vCard section numbers and heading. For documentation of errors, corrections, errata for vCard, please see [[vcard-errata]].

=== 3.3.1 TEL Type Definition ===

* The "type" for "TEL" lacks a "textphone" option (for the devices used by, e.g., people who are deaf or have speech difficulties. Example: [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)]. It may be good to consider adding a "textphone" value to the "type" for "TEL".
** +0 Tantek: I think a rethinking of the taxonomy of TEL types is merited, but I am uncertain whether it is worth growing the existing limited taxonomy or instead permitting user defined TEL types and thus allowing for natural evolution of a folksonomy of TEL types.
** +1 [[User:AndyMabbett|Andy Mabbett]]: There are a limited number of types. Note also the cell vs. mobile issue.
* The "type" for "TEL" lacks a "freephone" option. It may be good to consider adding a "freephone" value to the "type" for "TEL". Usually freephone numbers are not accessible from outside the country so it could help parsers with something?
* The "type" for "TEL" lacks an "SMS short code" option. (Raised in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011292.html e-mail, 2008-01-08 by Michael Smethurst])
* FYI. Some existing Personal Information Manager software practices:
** Mac OS X address book allows custom labels for TEL but not custom TEL TYPE per se, although for the user a custom TEL label just looks like a TEL TYPE
** Microsoft Outlook does not allow custom TEL TYPE values. Also, Microsoft Outlook has a "Company" telephone type, but unfortunately it isn't mapped to anything in vCard i.e. if you export a contact with a company tel, it is lost.
** Windows Mobile 6 displays SMS as a service that is only available if the telephone type is 'mobile'.
** Thunderbird 2 (Mac) does not allow custom TEL TYPE values.

Note: it might be a good idea to look at the [http://tools.ietf.org/html/draft-ietf-iptel-tel-reg-04 proposed registry for "tel:" URI parameters]; especially the [http://tools.ietf.org/html/rfc3966 "phone-context" URI parameter], since it tries to solve a similar problem. (per [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011295.html e-mail, 2008-01-08]).

=== 3.3.2 EMAIL Type Definition ===

* The "type" for "EMAIL" lacks distinction for various types of email, e.g. '''work''' or '''home'''.
* The "type" for "EMAIL" lacks dinstinction for give an alternative to the e-mail like a contact form.

=== 3.3.3 Suggestion for Types Definition ===

We can't have a generic type name cause we have to localize in french. so, for us, hCard work phone number is :
<nowiki><div class="tel">
Travail :
0321596224
</div></nowiki>

How will a bot recognize that type ? We cannot specify every types in every languages in the specification. That's why i think something like this would be better :
<nowiki>Travail : 0321596224</nowiki>

Please, use class and id attributes ONLY for micro formats specifications ! XML #cdata and #data are localized ! Thanks !

== Suggestions for New Properties ==
===Gender===
*There is no Card property for gender. A workaround: add the tag/category "male", "female", etc. See also [[hcard-faq#How_is_gender_represented|earlier discussion]] and [[genealogy-brainstorming#Gender]].
** -1 Tantek: I think tags/categories are good enough for now.
** +1 [[User:AndyMabbett|Andy Mabbett]]:Tags are often not appropriate, as per the cited discussion.

====Gender evidence====
See [[gender-examples]].

* Social network sites (see [[profile-examples]]) typically publish the gender of the individual. Please add such sites with specific URLs to the site, their editing UI, and their list of gender values to [[gender-examples#sites_and_services]].

* Many pages publish implicit gender information, not easily machine parsable - using names (Andrew, Andrea), titles (Mr, Mrs, Miss), relationships (husband, brother), pronouns (he, she), etc. Please add such pages with specific URLs and quotes of the explicit information, and the implied genders to the [[gender-examples#examples|gender examples]] page.

See also [[genealogy-brainstorming]].

===Deceased===

*See [[hcard-date-of-death]]

====Date of Death evidence====

*See [[hcard-date-of-death]]

===Instant Messaging===
*See [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770].

===Subject differentiator===
The use of "fn" and "fn org" differentiate between hCards for people and for other entities, but we perhaps need some further differentiator, between, say, organisations and venues (including buildings, governmental divisions, waypoints, etc.) at a level of granularity to be determined. [[User:AndyMabbett|Andy Mabbett]] 14:30, 11 Jul 2007 (PDT)

===Elevation===
*See [[geo-extension-elevation]]

===Global Location Number===
Global Location Number (GLN) - generally used in electronic commerce transactions [http://en.wikipedia.org/wiki/Global_Location_Number]. [[User:AndyMabbett|Andy Mabbett]] 06:43, 31 Aug 2007 (PDT)

===Initials===
For people, whose given-name is not stated (e.g. "A. N. Other"); to allow mark-up like:

<pre><nowiki>


A. N.
Other


</nowiki></pre>

===Alternative dates===

For historic figures, where no birth and/ or death dates are known a "'''flourished'''" date, or "'''flourished from'''"+"'''flourished to'''" pair, would be useful.

In genealogy, some people have no recorded birth date, but their "'''baptised'''" date is known.

===Continent===
<code>adr</code> should have an optional <code>continent</code> child-property.

== Suggestions for handling encodings ==
The vCard standard specifies that US-ASCII is assumed to be the encoding in the absence of a MIME content type header or a CHARSET parameter that indicates otherwise. This was an unfortunate choice. vCard .vcf files stored on a local filesystem do not contain a MIME header and the only way to reliably use an encoding other than ASCII is to tag each field with the "CHARSET=" label. This makes the vCard stream more complicated than necessary. This could be simplified by a revision of the standard that specifies UTF-8 as the default encoding. This could work safely with existing vCard .vcf files, which do not contain a MIME content header. The first vCard VERSION field would be the same encoded as either ASCII or UTF-8, so readers could easily determine which encoding to default to.

Furthermore, those creating vCard readers should be encouraged to support vCard .vcf files that begin with a UTF-8 BOM sequence. If the first three bytes of the file are 0xEF 0xBB 0xBF, the text file is UTF-8 encoded, and the vCard reader should assume UTF-8 is the default. Unfortunately many readers today fail to recognize the UTF-8 BOM and view the file as a corrupt vCard.

==Suggestions made elsewhere==

===WebDAV===

[http://www.ietf.org/internet-drafts/draft-daboo-carddav-02.txt vCard Extensions to WebDAV (CardDAV)]
<blockquote>defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. This document defines the "addressbook-access" feature of CardDAV.</blockquote>

===XEP-0154: User Profile===

[http://www.xmpp.org/extensions/xep-0154.html XEP-0154: User Profile] specifies how to represent and manage profile data about IM users and other [http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol Extensible Messaging and Presence Protocol] (XMPP) entities using the XMPP Data Forms extension. It has a far greater number of properties than vCard, but reinvents and re-names some of the latter's properties.

==Note==
On 2006-11-24, Paul Hoffman of the [http://www.imc.org/ Internet Mail Consortium], responsible for the development and promotion the vCard standard, wrote in response to an e-mail from [[User:AndyMabbett|Andy Mabbett]] informing him of this web page:
<blockquote>
There has been almost no interest in revising the vCard standard. This is due to lack of momentum, not the lack of good suggestions.
</blockquote>

However, see [[events/2007-09-18-calconnect-vcard-workshop]] for an event with vCard modification on the agenda.

== See Also ==

* [[vcard-errata|vCard errata]]
* [[vcard-implementations]]
* [[hcard|hCard]]
* [[hcard-brainstorming#Post_vCard_additions]]
* [http://www.imc.org/imc-vcard/ vCard mailing list] - a place to raise these issues, and where similar issues can be found.
* [[events/2007-09-18-calconnect-vcard-workshop]]

hcard-brainstorming

2008-01-08T01:54:51Z

Guillaume Lebleu: /* Implied work tel */

<h1> hCard Brainstorming </h1>
{{TOC-right}}
This page is for brainstorming about various uses and details of [[hcard|hCard]]. This page contains proposals. For the current state please see [[hcard|hCard]].

== Authors ==
* [http://suda.co.uk/ Brian Suda]
* [http://tantek.com/ Tantek Çelik] (formerly of [http://technorati.com Technorati, Inc])

== Contributors ==
* [[User:Atamido|Atamido]]
* [[User:ChrisMessina|ChrisMessina]]
* [[User:DimitriGlazkov|DimitriGlazkov]]
* [[User:AndyMabbett|Andy Mabbett]]
* ...
* ... and many others

== Problems Being Solved ==

Some of the problems that [[hcard|hCard]] helps to solve:

* having to enter business cards that go out of date (subscribe to someone's syndicated [[hcard|hCard]] instead).
* annoying "update your contact info" email from various centralized contact info services
* [[social-network-portability]] through the use of [[hcard-supporting-user-profiles|hCard supporting user profiles]] and [[hcard-xfn-supporting-friends-lists|hCard+XFN supporting friends lists]]

== Named locations ==
Most hCards contain contact information for people or organizations. But locations that aren't organizations are also deserving of their own hCard (e.g. somebody's house/apartment). This situation can be represented by combining "fn" and "extended-address".

=== "fn" and "extended-address" combination ===

'''Proposal''': Similar to [[hcard#Organization_Contact_Info|organization contact info]], if the "fn" property and an "extended-address" property have the exact same value (typically because they are set on the same element, e.g. <code>class="fn extended-address"</code>), then

# The hCard represents contact information for a place and SHOULD be treated as such.
# The author also MUST NOT set the "N" property, or set it (and any sub-properties) explicitly to the empty string "".
# Parsers SHOULD handle the missing "n" property by implying empty values for all the "n" sub-properties.

'''Further proposal''': Consider also an hCard for a City, "Birmingham, England": Birmingham may be the "fn" and the "locality", but it's not an "extended-address". Perhaps the rule should be that the hCard is for a place if the "fn" is on any address component (e.g "fn locality" or "fn street-address")?

=== Examples in the wild ===

* The named location "Picnic benches" in the address "Picnic benches, South Park, San Francisco, California" in [http://adactio.com/journal/1364/ a blog post on adactio.com].
<pre><nowiki>


Picnic benches
South Park
San Francisco
California


</nowiki></pre>

==== Potential examples in the wild ====

* The location "Phone Boxes by the Sealife Centre" [http://upcoming.yahoo.com/venue/5668/ on Upcoming] is currently marked up as "fn org":
<pre><nowiki>
<div class="vcard">
<div class="fn org">Phone Boxes by the Sealife Centre</div>
<div class="adr">
Marine Parade 
Brighton & Hove,
England
BN2 1TB 
United Kingdom 
01273 606674
</div>
<div class="note">Just a meeting place, in case the venue changes.</div>
</div>
</nowiki></pre>
This could be marked up as:
<pre><nowiki>
<div class="vcard">
<div class="adr">
<div class="fn extended-address">Phone Boxes by the Sealife Centre</div>
Marine Parade 
Brighton & Hove,
England
BN2 1TB 
United Kingdom 
01273 606674
</div>
<div class="note">Just a meeting place, in case the venue changes.</div>
</div>
</nowiki></pre>

===Concerns===
The above seems to be an elegant solution, but a wider variety of examples form published pages are needed, to be sure it meets all common scenarios. these should include cases where "adr" is not already used; note that in that case an extra level of nesting is required. The implications of this, for hCards already published, should be considered.

Also, what about hCards for published locations, which already include an extended address?

e.g.

<pre><nowiki>
<div class="vcard">
Powell's Pool

Sutton Park
Birmingham
England

</div>
</nowiki></pre>

[[User:AndyMabbett|Andy Mabbett]] 05:40, 15 Dec 2007 (PST)

=== named location formats ===
Previous named location format efforts:

==== Simple GeoRSS featurename ====
The [http://georss.org/simple Simple GeoRSS] vocabulary contains the following named location example in the "Additional Properties" section that references a <code>featurename</code> tag.

<blockquote><h3>Feature Type, Feature Name, and Relationship Tags</h3>The Feature Type, Feature Name, and Relationship tags are specified as GeoRSS elements.<pre><nowiki>
<georss:point>45.256 -110.45</georss:point>
<georss:featuretypetag>city</georss:featuretypetag>

<georss:relationshiptag>is-centered-at</georss:relationshiptag>

<georss:featurename>Podunk</georss:featurename>
</nowiki></pre></blockquote>

A [http://www.google.com/search?q=site%3Ageorss.org%20featurename search for featurename on georss.org] fails to find any other references however, including a definition.

An [http://lists.eogeo.org/pipermail/georss/2006-December/000895.html email on the georss list from Dec 2006] thread "featurename, other missing bits from the site" notes that "there is some updating to do" in response to a concern that "that descriptions of "featurename" are not present on GeoRSS Simple and the GeoRSS Model. GeoRSS GML makes no mention of the non-geometric properties at all."

== FN Nickname semantic ==
There are many sites (e.g. [http://flickr.com Flickr], [http://consumating.com/ Consumating]) which permit the user to '''both''' have a multi-word login/handle/alias, '''and''' not show their ''real'' name (fn, n, given-name, family-name etc.).

For the people represented by the profile pages of these sites, the best we can do is mark-up their login/handle/alias as their "nickname". Originally, we had thought that such handles etc. were single words only, and thus we created the [[hcard#Implied_.22nickname.22_Optimization|Implied nickname optimization]] accordingly, where you can markup the handle as an "fn", and have it automatically set a "nickname" property value, and empty values for all the "n" sub-values.

In order to deal with multi-word handles, similar to the [[hcard#Organization_Contact_Info|hCard Organization contact info]] method, the following is proposed:

=== "fn" and "nickname" combination ===

Due to the use of potentially multi-word nicknames/handles/usernames in content published on the Web, (e.g. on sites like [http://flickr.com Flickr] and [http://consumating.com/ Consumating]), hCard has a mechanism for specifying a multi-word "fn" that is also a "nickname" without affecting any "n" sub-properties that are otherwise specified, and explicitly implying empty defaults for "n" sub-properties.

Similar to the [[hcard#Implied_.22nickname.22_Optimization|implied "nickname" optimization]], if the "fn" property and a "nickname" property have the exact same value (typically because they are set on the same element, e.g. <code>class="fn nickname"</code>), then

# The content of the "fn" is treated as a "nickname" property value.
# Parsers should handle the missing "n" property by implying empty values for all the "n" sub-properties.

== Implied FN from N ==
Since the "n" property is more detailed and structured than the "fn" property, and [[hcard-examples-in-wild]] have shown that very often what is specified for "n" sub-properties is also specified for the "fn" property, we could add the following implied "fn" optimization which would permit sites to only use "n" and its subproperties.

In addition, some sites don't have contiguous uninterrupted text that represents the desired "fn" value, and would much rather have the "fn" implied from "n" subproperties. E.g. "Citizen Space Citizens" on [[hcard-examples-in-wild]].

=== implied "fn" from "n" optimization ===
If an hCard has no "fn", yet has an "n" property with one or more subproperties, then the "fn" property value can be implied by concatenating the "n" subproperty values as follows, with a space between each subproperty value, and multiple subproperty instances.

* 'honorific-prefix'es (as found in document order)
* 'given-name'
* 'additional-name's (as found in document order)
* 'family-name'
* 'honorific-suffix'es (as found in document order)

== Implied N from its subproperties ==
Since the "n" subproperties are sufficiently uniquely named (that is, they are not used by any other hCard property), and "n" is one of the [[hcard-singular-properties]], it is possible to consider leaving out the "n" property itself fo the hCard, and simply directlly using the subproperties, as properties of the hCard.

=== implied "n" from its subproperties ===
If an hCard has no "fn" nor "n" properties, then the entire scope of the hCard is considered to be inside an implied "n" property.

E.g. this markup:
<pre><nowiki>

Tantek
Çelik

</nowiki></pre>

would be treated from a parsing perspective as:

<pre><nowiki>

Tantek
Çelik

</nowiki></pre>

Which, with the '''implied "fn" from "n" optimization''', would then be effectively treated as:

<pre><nowiki>

Tantek
Çelik

</nowiki></pre>

* a related request from the mailing list: http://microformats.org/discuss/mail/microformats-discuss/2007-September/010791.html

== Examples ==

* See [[hcard-examples]], which provides several illustrative instructive examples, as well as 1:1 hCard examples for each example in [http://www.ietf.org/rfc/rfc2426.txt RFC 2426].

=== Using RFC2806 with hCard ===

[http://www.ietf.org/rfc/rfc2806.txt RFC 2806] defines the telephone scheme "tel:", "fax:" and "modem:" to handle phone communications with URIs in the same way, "mailto:" is defined for email. It's part of the list or registered schemes by IANA : [http://www.iana.org/assignments/uri-schemes Uniform Resource Identifier (URI) SCHEMES]

<pre><nowiki>
tel telephone [RFC2806]
fax fax [RFC2806]
modem modem [RFC2806]
</nowiki></pre>

It is practical to write your tel number like this.

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">+1-919-555-7878</a>
</nowiki></pre>

or even

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">Mr Smith's phone</a>
</nowiki></pre>

You can add support for "tel:" to your desktop and to your browser

* For Gnome, edit ~/.gnome/Gnome and add something to the URL Handlers section. (Dan Connolly uses this to get galeon to launch telnum from [http://dev.w3.org/cvsweb/2001/telagent/ telagent sources] for tel URIs)
* In Mozilla, [http://dizzy.mozdev.org/ Dizzy]
* In Internet Explorer, [http://msdn.microsoft.com/workshop/networking/pluggable/overview/overview.asp Asynchronous Pluggable Protocols]

On the CSS front… You could for example add automagically an icon. I have put the property !important for those who wants to add it to their own stylesheet in their browsers, so they know type of links when browsing.

<pre><nowiki>
a[href^="tel:"]:before {
content: '\260f ' !important;
padding-left: 20px !important; }

a[href^="mailto:"]:before {
content: '\2709 ' !important;
padding-left: 20px !important; }
</nowiki></pre>

== Encoding "modern" attributes ==

Since vCard was first established, various interactive communication technologies and addressing schemes have been widely adopted. Although there aren't specific properties for these technologies / addressing schemes, they can be captured as URLs or email addresses.

This has now been written up for the most part. See:

http://microformats.org/wiki/hcard-examples#New_Types_of_Contact_Info

Still to be addressed:

* iChat mac.com addresses, simply store "@mac.com" email addresses, e.g.
** <code><nowiki><a class="email" href="mailto:steve@mac.com">...</nowiki></code>
* MSN Instant Messenger, you can simple store "@hotmail.com" or "@msn.com" or "@passport.com" email addresses.
* Internet Relay Chat (IRC), use "irc:" URLs.

== Auto-Discovery ==

=== Representative hCard discovery ===

See [[representative-hcard]].

=== vCard link rel auto-discovery ===

A similar possibility is an auto discovery link in the head of the document could point to a URL (perhaps with transform) to a vCard version of the representative hCard.

On the page with the hCard encoding, the best link would be as follows:
<code><nowiki> <link rel="alternate" type="text/directory" href="..." /> </nowiki></code>
this HTML page is an alternate view of the vCard.

The [http://www.iana.org/assignments/media-types/text/ registered and appropriate type] for vCard entities is “text/directory”, as defined in Internet RFC 2425, “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”.

It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, [http://bjoern.hoehrmann.de/ Björn Höhrmann] sent to the [http://www.w3.org/2002/05/html/charter HTML Working Group] a [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de request for clarification] on the issue.

When on a different page, referencing that encoded page in the href would ''not'' be an alternate view of the current page. Therefore rel="alternate" may not be appropriate. The problem of what rel value to use is bigger than links to vCards.

=== hCard to hCard relationships ===

There are several types of hCard to hCard relationships, that is, one hCard hyperlinking to another hCard which would beneift from the explicit rel values that described the specific relationship.

==== mini hCard to expanded hCard ====

Perhaps the most common type of hCard to hCard link is a mini hCard, e.g. from a personal home page or blog to the person's contact/about page, perhaps consisting of only a name and URL, that links to an expanded hCard. Examples in the wild:

In this instance, possible rel values might include:
* rel="expanded"
* rel="definitive" - the problem with this is that the expanded hCard is not necessarily a definitive version.
* rel="canonical" - similarly, the expanded hCard is not necessarily at a canonical URL. It may simply be *an* expanded version, not *the* expanded version.

The following rel values have been suggested, but are not really a good idea due to the fact that they imply a dependence to add a new rel value for any new microformat which might have a mini-version linking to a more expanded version:
* rel="author"
* rel='contact'
* rel="contactinfo"
* rel='hcard'
* rel='person'

Here are some more generic values that have been suggested which perhaps make even less sense:
* rel='microformat' - this doesn't make any sense when you imagine a world where nearly every web page contains microformats.
* rel='about' - what does "about" have to do with a person or even authorship?
* rel="profile" - should be reserved for meaning here is an [[xmdp|XMDP]] profile for the current page.
* rel='PIM' - not sure about how this makes any sense either.

==== mini hCard to remote site ====
Per the instructions in [[hcard-examples]] for [[hcard-examples#References_to_People_in_Blogrolls|marking up people in blogrolls]], you might have an hCard of your site for another person which then links to that other person's website. Should there be a rel value that indicates this "mini-hCard" to "person" relationship?

==== mini hCards and nearby expanded hCard links ====
Some authors include mini-hCards on their pages of themselves (e.g. in their blog posts), and yet those mini-hCards don't actually point to more expanded versions. However, sometimes they have a separate but nearby link on the same page like "about" or "contact" that does link to an expanded hCard.

E.g. on [http://factoryjoe.com/blog/ FactoryCity], blog posts have mini-hCards for "published by", e.g. (white space added for readability):
<pre><nowiki>
Published by

<a href="http://factoryjoe.com/blog/author/factoryjoe/" class="url fn">
Chris Messina
</a>

</nowiki></pre>

On those same blog pages, there is a link labeled "Contact Information" that links to http://factoryjoe.com/blog/hcard/ which has an hCard with more information like phone number, birthday etc.

=== Auto-Discovery for XFN ===

An author will typically their XFN information on a specific page, rather than all pages. In particular, a specific page separate from the home page of their blog, and thus it would be useful to have an explicit rel value to assist in auto-discovery of XFN information.

This was suggested by Jens Alfke on 20050606 at the WWDC blogger's dinner.

== geo improvements ==
''See [[geo-brainstorming]]''

== Other use cases ==
Please add your suggestions!

hCard microformats could be used to:
*Calculate and display the subject's age "as of today".
*Calculate and display the subject's age at death (if a [[hcard-date-of-death|Date of Death]] is available)
*Generate an recurring iCal for a living subject's birthday
*Generate an recurring iCal for a dead subject's "anniversary of birth" (if a [[hcard-date-of-death|Date of Death]] is available)
*...

== Issues with vCard Applications ==
See [[vcard-implementations]].

== Open Questions ==

Q: since many of the components would be using CSS classes for encoding data, it is possible to MIX two different profiles. (e.g. hCard and XFN) There are no real constraints on where/how to enforce class names, these are based on the html profile, since it is difficult to associate the text within the attribute to a specific profile.

<pre><nowiki>
...
<a href="mailto:joe.smith@example.com" class="fn" rel="met">Joe Smith</a>
...
</nowiki></pre>

-- [http://suda.co.uk/ Brian Suda]

Q: Preserving White space? Should the transforming applications preserve extra white space characters? For example:
<pre><nowiki>
<a href="http://mywebsite.com/" class="fn n">
John
Q.
Public
</a>
</nowiki></pre>

When transformed into a vCard, the N property will pick apart the span tags and create the value for N correctly seperated by colons. The FN property will take a string and simply display it. There are two possible renderings for FN:
<pre><nowiki>
John Q. Public

John
Q.
Public
</nowiki></pre>

Either the white-space is preserved or it is not. Which should the transforming applications render?

-- [http://suda.co.uk/ Brian Suda]

A: The parsing application should follow the white space collapsing rules of the mime type it retrieves. I.e. if it retrieves a "text/html" document, it should do HTML white space collapsing.

-- [http://tantek.com/log/ Tantek]

Many of the Questions and Answers are relevant to both ["hCal"] and hCard.

Q: Would it be appropriate to wrap the name of the vCard owner with <dfn/>? This may give the hCard some added semantic value in the XHTML document.
<pre><nowiki>



<a class="internet" href="mailto:jfriday@host.com">
<dfn>
Joe Friday
</dfn>
</a>

+1-919-555-7878
Area Administrator, Assistant


</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]
* If the answer to the above Q is "yes", why not use the following?
<pre><nowiki>
<dfn class="fn">Joe Friday</dfn>
</nowiki></pre>
or
<pre><nowiki>

<dfn class="vcard">

<a class="internet" href="mailto:jfriday@host.com">
Joe Friday
</a>

+1-919-555-7878
Area Administrator, Assistant
</dfn>

</nowiki></pre>
This would mark the entire hcard as the "defining instance".

[[User:Bob Jonkman|Bob Jonkman]] 10:07, 13 Jul 2007 (PDT)

== Applications ==
Applications that are hCard aware or can convert hCard to vCard formats.

=== Copy hCards favelet(s) ===
* I think a Favelet would work nicely here. When you find a page that is hCard friendly, you click the favlet and you get yourself a vCard. This is done! See X2V in the implementations section of the [[hcard|hCard]] spec.

=== Distributed Commentor Icons ===

''The URL reffered to in this section is no longer available. The thoughts on using icons are however still relevant.'' [[User:WilleRaab|WilleRaab]] 16:55, 23 Jul 2007 (PDT)

* See [http://thedredge.org/2005/06/using-hcards-in-your-blog/ using hCards in your blog] for an example of hCards used for comment authors (commentors). The system used there, "Gravatars", is a centralized site that serves commentor icons that requires login etc.

What if we gave each commentor the option of hosting their own icon?

A distributed commentor icon implementation could work like this:

# Given the URL of a commentor, look for an <code><address></code> element with classname of "vcard" at the commentor's URL. The <code><address></code> element is supposed to be the contact information for the page (see [[hcard-faq|hCard FAQ]] for more info), so this makes sense.
# Next, look for the first element inside that hcard that has a classname of "logo".
# Hopefully that element is an <code><img></code>, and if so, use its src to get the commentor's icon.
# Presto. You've got distributed commentor icons!

== Spam prevention ==
hCard uses <code>mailto:</code> links, and therefore
it automatically "inherits" the disadvantage of <code>mailto:</code> links:
These links can be easily detected by emails spiders (used by spammers).

Email addresses are picked up like any other link crawled by a search engine and trustworthy crawlers may be deterred from adding emphasis while indexing these links by including rel="nofollow" (See [[rel-nofollow]]). However, email addresses used for spam are crawled by email spiders which will likely ignore this attribute.

There are ways to prevent email address detection by simple email spiders, while
still retaining full compatibility with (X)HTML applications.
One common way is to "encode" the the "m" of "mail" and "@" with character entities, yet it's unwise to follow a convention of only encoding specific characters because the email spiders can pick up on this too:

Example of the original link:
<pre><nowiki>
<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>
</nowiki></pre>

Example of the "encoded" link (with rel-nofollow added):
<pre><nowiki>
<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;example.com">john.smith&#064;example.com</a>
</nowiki></pre>

Simple email spiders which do not do character entity decoding will therefore not be able to find your email address.

''Note:'' Perhaps there are or will be email spiders which can decode entities, so the this technique will only help with some (cheap) email spiders.
(See also: http://rbach.priv.at/Misc/2005/EmailSpiderTest)

=== Other prevention methods to consider ===
* Using server-side code to implement character entities randomly
* Displaying the address in a way thought to be only human readable (thus breaking the link):
** Using an image instead of text (could still be machine readable using OCR)
** Using human readable text that conveys the need for editing before use (eg PLEASE-NO-SPAM_name@example_NO-SPAM.com)
* Using javascript for client-side decryption of an encrypted address (requires javascript to be enabled)
* Pointing to an email form or other URL instead of an email address

== Tutorials ==
* How to hCard encode entries in Popular blog software.
* Good reasons to publish your hCard
** as a business, get people to put you in their address book so they'll find you later
** as a business with an email list, get people to add you (with email address) to their address book so that your email list works via whitelisting via the address book.

* [http://24ways.org/2006/styling-hcards-with-css Styling hCards with CSS] is a text on how to use CSS to make an improved presentation of an hCards contents.

== Parsing ==
See separate [[hcard-parsing|hCard parsing]] page for current hCard parsing rules.

Add thoughts/proposals to improve/add to hCard parsing here in this section in hCard brainstorming, and be sure to include URLs to examples of hCards in the wild which could benefit from parsing rule changes.

=== Additional Semantic HTML handling ===
==== <code>acronym</code> element handling ====
Choices:
* Explicitly treat <code>acronym</code> the same as <code>abbr</code>, per semantics of the '<code>title</code>' attribute on <code>acronym</code> in particular, as defined in HTML4.01.
* Explicitly treat <code>acronym</code> the same as <code>span</code>, and discourage use of <code>acronym</code>.

==== <code>input</code> element handling ====
In [[hcard-parsing]], I've defined special-case handling for several elements according to [[hcard-parsing#more_semantic_exceptions|more semantic exceptions]], e.g. textual properties on the <code>img</code> element use the 'alt' attribute.

One element I forgot at the time was the <code>input</code> element, specifically, <code><nowiki><input type="text"></nowiki></code>. Another I forgot was the <code>textarea</code> element.

The simple suggestion is to add the following to [[hcard-parsing]], specifically to the [[hcard-parsing#all_properties|all properties]] sub-section:

* <code><input type="text" value="..."></code>: use the value of the 'value' attribute. If there is no 'value' attribute then treat the value as empty. Interactive user-agents {{must}} use the [http://www.w3.org/TR/html4/interact/forms.html#current-value current value] of the element.
** consider other input types also (e.g. checkbox, radio, hidden) and specify how to parse them as well.
* <code><textarea></code>: use the text contents of the element. Interactive user-agents {{must}} use the [http://www.w3.org/TR/html4/interact/forms.html#current-value current value] of the element.

[[User:Tantek|Tantek]]

==== forms auto-fill ====
If you go to a site that needs your contact info for something, say an ecommerce site for checkout, and if the form fields are marked up with hCard semantics per the above, then perhaps we could consider having that mean "insert hCard here".

Interactive useragents (e.g. [[operator]] on [[firefox]]) could detect such "insert hCard here" semantics in forms on pages, and let you "pre-fill" with *your* hCard info, and then all of a sudden we have a standard for forms auto-fill, rather than all the hacks that have gone into browsers since 1999 (starting with IE4.5/Mac which I'm pretty sure was the first to do forms auto-fill of an entire form with a single button press - not just auto-complete of each form field individually).

Obviously this would make sense to build into *existing* forms auto-fill features in [[Firefox]] and [[IE]], and any other browsers that support it.

For more on this, see the 2007 August blog post [http://dbaron.org/log/2007-08#e20070818a hCard autofill?] by David Baron, a Mozilla employee.

This way new sites could simply conform to the standard, rather than depend on hacks which parse label values etc. and imply things and get them wrong sometimes.

'''[[i18n]]''' advantages: hCard annotated form inputs would also be more international, thus avoiding the need for each browser to guess what is the "name" and "telephone" field in every language, so they can do forms auto-fill on any site regardless of language, not just English.

[[User:Tantek|Tantek]] 16:24, 23 Jul 2007 (PDT)

==== Background discussion: ====

Key threads:
* http://microformats.org/discuss/mail/microformats-discuss/2006-September/005951.html
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006132.html
* http://microformats.org/discuss/mail/microformats-discuss/2007-January/008312.html

Somewhat related:
* http://microformats.org/wiki/rest/forms-brainstorming
* http://microformats.org/wiki/rest/forms-examples

One key summary:
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006172.html

The options discussed in a hypothetical hCard input system so far appear to be:

1) create a new root class other than vcard to indicate a form that's
fillable with hCard data.

Proposed markup:

<pre><nowiki>
<form class="vcard-input" ...>
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" />
<input type="text" class="family-name" name="last_name" />
</fieldset>
...
</form>
</nowiki></pre>

Benefits:
Doesn't overcomplicate hCard with new parsing rules,
doesn't require rewrite of existing parsers to ignore 'unparsable' data.
Drawbacks:
Requires completely new parsers to be written.
Existing parsers would ignore data even if a valid hCard could be extracted.

2) extend hCard's parsing rules to cover form elements and relying on
the FORM/INPUT semantics to indicate that stuff is inputtable.

Proposed markup:

<pre><nowiki>
<form ...>
<div class="vcard">
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" value="Rob" />
<input type="text" class="family-name" name="last_name" value="Manson" />
</fieldset>
...
</div>
<div class="vcard">
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" value="Scott" />
<input type="text" class="family-name" name="last_name" value="Reynen" />
</fieldset>
...
</div>
</form>
</nowiki></pre>

Benefits:
Small addition to existing format rather than new one.
Semantics of an input form and the eventual display format are the same.
Drawbacks:
Existing parsers would/could parse forms as invalid hCards, would need re-writing.

Broader question:
* http://microformats.org/discuss/mail/microformats-discuss/2005-September/001059.html
Should this be extended beyond just hCard?

==== Key Issues/discussion points ====
* Extending parsing rules to extract value attributes from <input type="text|hidden"> fields
- ''Negative'' : this require adding a bit of special case to existing parsers to handle these elements
- ''Positive'' : this could help to enable uf based auto form filling
- ''Negative'' : this could help to enable uf based auto form filling (e.g. spam automation)
* Existing server side and client side scripts use non-hCard field names so class is the most seamless extension point
- ''Positive'' : this is in line with the current parsing model
* Many parsers (e.g. [[Operator]]) parse the loaded html not the dynamic DOM
- ''Negative'' : parser doesn't pickup any updated form data after the page has loaded
- e.g. even though textarea appears to parse ok - it's only ever the initially loaded value that can be exported
* Forms may contain more than one hCard so using <FORM class="vcard"> should not be required
- ''Positive'' : this minimises the changes to current parsing rules
* Empty values should be ignored when extracting hCards
* hCards with all empty values should be ignored when listing/extracting hCards
* Which form elements should be supported beyond input fields
- ''Examples''
- title select that lists mr/mrs/ms/dr/etc.
- checkboxes to choose which addresses to use
- ''Option'' : simplify extension to only support input fields and recommend that select's, radio buttons and checkboxes update related hidden input fields with simple javascript (e.g. onChange/Click="this.form.elements[this.className].value = this.value")
- Unworkable. Cannot require clientside javascript.
- ''Positive'' : this would simplify parsing and server side form processing as only single input fields for each value need to be used/validated
- ''Negative'' : hCard forms then require javascript if they use form elements other than basic <input type="text|hidden">
- ''Comment'' : either way any auto form filling will be more complex beyond simple <input type="text|hidden"> fields
- hypothetical comment assuming more complexity beyond.

[[User:RobManson|RobManson]]

=== multiple type parsing ===
* Multiple Type parsing / Type Optimization: The spec allows for, and the [[hcard-authoring#Phone_Numbers|hcard-authoring]] demonstrate the use of multiple type designations for a single value of tel. The syntax used in the authoring examples where each seems like it could become cumbersome. As these type designations are all single 'word' strings it may be possible to implement additional parsing rules to allow for multiple types inside the same HTML element. Handling delimiters may be an issue [space, comma, etc?], and some in-the-wild usage of multiple types would need to be located and examined before considering additional parsing rules along these lines [ [[User:ChrisCasciano|ChrisCasciano]] 10:21, 16 Apr 2007 (PDT) ]

=== fax and modem hyperlink parsing ===
For the "tel" property in particular, when the element is:
* <code><a href="fax:..."></code> OR <code><area href="fax:..."></code> : parse the value of the 'href' attribute, omitting the "fax:" prefix and any "?" query suffix (if present), in the attribute. For details on the "fax:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "fax" in addition to any explicit subproperty type specified on the 'tel' property.
* <code><a href="modem:..."></code> OR <code><area href="modem:..."></code> : parse the value of the 'href' attribute, omitting the "modem:" prefix and any "?" query suffix (if present), in the attribute. For details on the "modem:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "modem" in addition to any explicit subproperty type specified on the 'tel' property.

=== Ambiguous name components ===

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

===ADR with no children===
Parsers (Operator, Tails, Almost Universal Microformat Parser) currently expect <code>adr</code> to have one or more sub-properties. It is not clear from the hCard spec that that's mandatory (though the vCard RFC requires it); nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity.

Consider Wikipedia, whose templates often have a "locale" or "place" field, used, for example, on these articles about railway stations:

*[http://en.wikipedia.org/wiki/Old_Street_station Old Street]
**"Place" ("locale" in the template) is a '''street'''
*[http://en.wikipedia.org/wiki/Hamstead_railway_station Hamstead]
**"Place" is a '''local district'''
*[http://en.wikipedia.org/wiki/Inverness_railway_station Inverness]
**"Place" is a '''city'''

Likewise, the Wikipedia template for organisations, in which a "headquarters" address (for a business, for example) may contain a full or partial postal address, or just a city/county or city/country pair:

*[http://en.wikipedia.org/wiki/Tesco Tesco]
*[http://en.wikipedia.org/wiki/BP BP]
*[http://en.wikipedia.org/wiki/Google Google]
*[http://en.wikipedia.org/wiki/Blue_Coat_Systems Blue Coat Systems]

==== implied single adr subproperty ====
I propose that, where <code>adr</code> has content, but no explicit sub-properties, there should be a default sub-property to which that content is allocated, in order that it is captured by user agents, and can later be manually tweaked (in, say, an address book programme) by users if so desired. This would satisfy the vCard requirement for child-of-adr, and adhere to the general principle to "[[be-strict|be strict in what you send but generous in what you receive]]".
*Note that there may be other reasons to consider this suggestion, such as "ease of authoring". Another way of looking at this suggestion is as a "adr/extended-address shorthand". [[User:Tantek|Tantek]] 08:28, 26 Mar 2007 (PDT)

* there is also a LABEL property which is NOT structured data, but purely a text string to be used when labeling. LABEL purpose: To specify the formatted text corresponding to delivery address of the object the vCard represents. [[User:Brian|Brian]] 13:18, 30 Mar 2007 (UTC)
**On re-reading this, it seems that none of the adressess given in my examples meet the criteria of being "''formatted text corresponding to delivery address''". [[User:AndyMabbett|Andy Mabbett]] 03:35, 17 Apr 2007 (PDT)

Of the available sub-property options:

*street-address
*extended-address
*region
*locality

I suggest that "extended-address" is the most sensible sub-property to use, for this purpose. [[User:AndyMabbett|Andy Mabbett]] 03:57, 26 Mar 2007 (PDT)

==== implied adr subproperties ====
It may be possible for parsers to parse out adr subproperties from a contiguous adr string. This would be an optimization for both [[adr]] and [[hcard|hCard]].

This may also be too difficult/complex to be dependable or interoperable, but it is worth at least documenting our considerations and analysis either way.

Examples:

[http://www.ibm.com/contact/employees/us/ IBM's Employee Directory] search [http://www.ibm.com/contact/employees/servlets/lookup?country=us&language=en&search_country=all&lastname=Kaply&firstname=Michael returns hCards with the "adr" property] which contain the "locality" and "country-name" data but unfortunately without being marked up as such, e.g.:

<pre><nowiki>
<td class="adr">Austin, USA</td>
</nowiki></pre>

We could first define a canonical ordering of how to parse for comma (and perhaps in some cases space) separated adr subproperties within an adr string e.g.:

* 'post-office-box'
* 'street-address'
* 'extended-address'
* 'locality'
* 'region'
* 'postal-code'
* 'country-name'

Given a dictionary of country names and abbreviations, it may be feasible to parse for a country name at the end of the adr string, and then apply country/locale specific parsing rules to the rest of the adr string.

E.g.
* from a theoretical dictionary of country names:
** US|USA|United States|United States of America|Etats-Unis d'Amerique
* parse the remainder of the adr string backwards as follows:
** preceding that, look for a 5 or 9 digit (with optional dash '-' separator between digits 5 and 6) postal-code, and if found use it for the 'postal-code'
** preceding that, look for the name of a US state (e.g. California or any of the other states or territories available from a canonical list) or 2 letter state abbreviation (e.g. CA), and if found use it for the 'region' subproperty
** preceding that, look for the name of a US city (e.g. San Francisco, Los Angeles or any other US city available from a canonical list) or common city abbreviation (e.g. SF, LA), and if found use it for the 'locality'
** preceding that, look for common extended address details, such as: #|apt|apartment|suite|ste followed by a word consisting of letters and numbers, and if found use it for the 'extended-address'
** preceding that, look for a common street name bracketed by the street number (an integer with optional fraction and/or letter), and an optional street type (av|ave|avenue|blvd|boulevard|cir|circle|pl|place|st|street), and if found use it for the 'street-address'
** preceding that, look for a common post office box, with the pobox literal string: pob|pobox|PO Box followed by a word consisting of numbers and letters, and if found use it for the 'post-office-box'
* ... other countries

The above heuristic (not quite well specified enough to be an algorithm, yet) would allow parsing of the IBM Employee Directory result documented above.

There are a lot of existing geocoder APIs that turn unstructured addresses into structured ones - we should examine these for patterns and best practices. eg [http://www.google.com/apis/maps/documentation/#Geocoding_Structured Google's geocoder] [http://exogen.case.edu/projects/geopy/ geopy calls multiple ones]

==== adr without children FAQ ====
I think for now the simplest and most interoperable (and what I think implementations already do) is to make this an FAQ (because the spec already doesn't say to do anything with adr without any subproperty)

Q: What should a parser do with an "adr" property lacking any subproperties?

A: A parser SHOULD do nothing with such an "adr" property. A parser MAY provide the text content of such an "adr" property in the results of its parsing as a freeform value of the "adr" property. Note that the vCard standard does not allow for any such freeform value of its "adr" property (in vCard the "adr" property MUST be structured) and thus that MAY suggestion to parsers only applies in situations (such as APIs, JSON return values) where it is possible to return a freeform value for the "adr" property.

[[User:Tantek|Tantek]] 09:20, 2 Aug 2007 (PDT)

== Birthday Reminders ==
*hCard consumers could calculate the current age of hCard subjects, from the DoB. [[User:AndyMabbett|Andy Mabbett]] 07:47, 20 Apr 2007 (PDT)
*for hCards with DoB, hCard consumers could generate and export a recurring hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:06, 20 Apr 2007 (PDT)
**If/ when [[hcard-date-of-death|Date of Death]] is added to hCard, parsers could instead generate a recurring "death-anniversary" hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:08, 20 Apr 2007 (PDT)

== Post vCard additions ==

Keeping hCard properties and values as a 1:1 representation of vCard properties and values has numerous benefits such as simplicity, stability, interoperability with the vast number of existing vCard applications etc.

However some have found vCard to be limiting in terms of the data/properties/fields they want to express in contact information. Some implementations use vCard extensions to express such information [citation needed].

This section is for documentation of such suggested additions. Empirical evidence of actual *real world* examples on the Web of people publishing this information would be a good step towards considering any such additions/extensions.

* '''altitude'''. From [[hcard-issues]].
**See [[geo-elevation-examples]]
* '''vat-number''' : for VAT numbers of companies, which are used a lot in Europe and they need to be published on Belgian publications (including websites).

* '''gender'''
** See [[vcard-suggestions#Gender]]

* '''date-of-death'''
** See [[hcard-date-of-death]]

Thus see (and add to): [[vcard-suggestions]]

Another path to consider is the development of another microformat which includes an hCard and then extends it with additional properties for a particular domain. In many ways [[hresume|hResume]] has already done this. Other related efforts:
* [[genealogy]]
* [[profile]]

Using hCard as a stable building block for additional microformats may seem more desirable than incrementally growing hCard itself.

Of course if vCard were extended itself, that may provide impetus to add such extensions to hCard in order to maintain the 1:1
representation of properties/values.

==Wikipedia's Persondata==
Wikipedia's [http://en.wikipedia.org/wiki/Wikipedia:Persondata Persondata] aligns very closely with hCard, but has additional date and place of birth & death fields. [[User:AndyMabbett|Andy Mabbett]] 13:02, 28 Jan 2007 (PST)

== TODO ==

* The [[hcard-profile]] needs verification and perhaps a URL for retrieving the actual XMDP, rather than as <pre> text on a wiki page.
* Complete translating the examples from the vCard spec into hCard, and place them on a separate hCard examples page.
* Create a "rich" but realistic hCard example, say for example for a salesperson, who wants to put a whole bunch of contact information on their website in order to be found/contacted easily.
* Provide examples of how to encode instant messaging (IM) accounts. Figure out what would the mailto: or aim: URL in hCard look like in vCard. And take a look at what vCard applications do today with IM addresses.
* Clarify contradictory copyright statements, per http://microformats.org/discuss/mail/microformats-discuss/2007-July/010243.html

== CSS Styles ==
Not only can you create semantics with the hCard values, but you can add CSS styles to them as well. You are free to style the terms in any way you want, but here we can list a few ideas for how to style terms.

If you want to encode hCard data, but do NOT want to display it in the HTML code (WARNING: This is very much recommended AGAINST, and in general against the microformat principle of marking up visible data), then you can hide that tag in CSS with the following code:
<pre><nowiki>
Hidden Data
</nowiki></pre>
Transforming applications will still find the data and use it when converting hCards to vCards.

== Other Implementations/Ideas ==
* [http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Representing vCard Objects in RDF/XML] This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
* It would also be possible to convert XFN and hCard to FoaF.
* [http://microid.org/ MicroID in hCard]

== Accepted Suggestions ==

=== Encoding Company data as a Business Card (proposal) ===

( Accepted: http://microformats.org/wiki/hcard#Organization_Contact_Info )

In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.

Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.

Note that [http://microformats.org/wiki/vcard-implementations#organization_vs._individual Apple Address Book supports this semantic when importing vCards].

See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.

=== Implied "FN and N" Optimization (proposal) ===

Right now a parser first looks for an "n" element.

And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.

BACKGROUND:

Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.

PROPOSAL:

We should consider adding one more implied optimization after the steps documented above and that is:

If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.

This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.
* +1 [[User:Atamido|Atamido]]
* +1 [[User:ChrisMessina|ChrisMessina]] - note: multiple alternate nicknames should also be allowed
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]

== Rejected Suggestions ==

Suggestion: ''The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.''

Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example:
<pre><nowiki>

...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...

</nowiki></pre>

There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.

== References ==
=== Normative References ===
* [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] vCard RFC
* [http://www.ietf.org/rfc/rfc2397 RFC 2397] data URI RFC
* [http://gmpg.org/xmdp/ XMDP]
=== Informative References ===
* [http://www.imc.org/pdi/ Personal Data Interchange (PDI) at the Internet Mail Consortium]
* [http://tantek.com/log/2004/07.html#d27t1049 Markup language design notes]
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class]
* [http://www.icao.int/mrtd/download/technical.cfm ICAO - Machine Readable Travel Documents format]

== Related Pages ==
{{hcard-related-pages}}

== Implied work tel ==

=== Problem ===

Some phone numbers are not always documented of type 'work'. The type 'work' is usually implied from context.

=== Examples in the wild ===

[[http://www.nvidia.com/page/contact_information.html NVidia contact information]]

Only 'Tel' is specified. The fact that it is of type 'work' can be assumed from the context: the name of an organization is present.

<pre>
NVIDIA CORPORATE OFFICE: 
2701 San Tomas Expressway 
Santa Clara, CA 95050 
Tel: 408-486-2000 

Fax: 408-486-2200 
...

</pre>

[[http://www.supermarketguru.com/page.cfm/369 Supermarketguru.com]]

<pre>


Phil Lempert: <a href="mailto:plempert@supermarketguru.com">plempert@supermarketguru.com</a> 

SupermarketGuru.com 
3015 Main Street, Suite 320 Santa Monica, California 90405 
Telephone: 323-860-3070


</pre>

Here only 'Telephone:' is specified, a FN is present ('Phil Lempert') but because an ORG is present ('SupermarketGuru.com'), it can be safely implied that '323-860-3070' is a tel or type work.

=== Proposal ===

If an ORG is present in a VCARD, a TEL with no TYPE has an implied TYPE 'work'

hcard-brainstorming

2008-01-08T01:42:15Z

Guillaume Lebleu: Added Implied work tel section

exploratory-discussions

2008-01-05T20:21:25Z

Guillaume Lebleu: /* other active */

<h1>Exploratory Discussions</h1>
{{TOC-right}}
Per the microformats [[process]]: research and analysis of real-world [[examples]], existing formats, and brainstorming to motivate the microformat. Please check [[rejected-formats]] before making additions.


==Active==

The following exploratory discussions are being actively pursued (generally, edited in the last month, or with an active community member (named in parentheses) having expressed an interest in pursuing them)

=== media related ===
Media related efforts are very active in the microformats community and thus have been grouped here for convenience
* [[audio-info]] ([[audio-info-examples|examples]], [[audio-info-formats|formats]], [[audio-info-brainstorming|brainstorming]], [[audio-info-proposal|proposal]], [[audio-info-issues|issues]], [[haudio|specification]]) - Marking up information and metadata related to audio (speech, music, and sound in general). ([[User:ManuSporny | Manu Sporny]])
** music [[music-examples|music examples]]
* audio-album (see [[audio-info]] pages for examples, formats, brainstorming. [[audio-album-proposal]], [[audio-album-issues]]) - Marking up information and metadata related to audio albums/collections. ([[User:ManuSporny | Manu Sporny]])
* broadcast: Internet Radio & TV: [[broadcast-examples]], [[broadcast-brainstorming]] ([[User:Chris Newell|Chris Newell]])
* [[media-info]] ([[media-info-examples|media-info examples]], [[media-info-formats|media-info formats]], [[media-info-brainstorming|media-info brainstorming]])
* photo note [[photo-note-examples|photo note examples]]
* show [[show-examples]], [[show-formats]], [[show-brainstorming|show brainstorming]] (see also [[media-info]])
* showroll [[showroll-examples]], [[showroll-formats]], [[showroll-brainstorming]]
* video-info ([[video-info-examples|examples]], [[video-info-formats|formats]], [[video-info-brainstorming|brainstorming]], [[video-info-proposal|proposal]], [[video-info-issues|issues]]) - Marking up information and metadata related to video (video clips, movies, television, and video multimedia presentation in general). ([[User:ManuSporny | Manu Sporny]])

=== other active ===
* alternates [[alternates-brainstorming|alternates brainstorming]], [[alternates-examples|alternates examples]] ([[User:JeffMcNeill|Jeff McNeill]])
* [[currency]]; [[currency-examples]]; [[currency-formats]]; [[currency-brainstorming]]; [[currency-proposal]]; [[currency-issues]] ([[User:AndyMabbett|Andy Mabbett]])
* group [[group-examples|group examples]], [[group-formats]], [[group-brainstorming|group brainstorming]]
* items [[items-examples|items examples]], [[items-formats]], [[items-brainstorming|items brainstorming]]
* measures and measurement units [[measure]], [[measure-examples]], [[measure-formats]] [[User:AndyMabbett|Andy Mabbett]]
* receipt ([[receipt-examples|examples]], [[receipt-formats|formats]], [[receipt-brainstorming|brainstorming]], [[receipt-proposal|proposal]]) - Marking up information and metadata related to purchase receipts. (Leif Arne Storset)
* recipe [[recipe-examples|recipe examples]], [[recipe-formats]], [[recipe-brainstorming]] ([[User:Phae | Frances Berriman]])
* [[species]] - for the marking up of the scientific names of living things: [[species-examples]], [[species-formats]], [[species-brainstorming]] ([[User:AndyMabbett|Andy Mabbett]]) 
* syllabus [[syllabus-examples]], [[syllabus-formats]], [[syllabus-brainstorming]] {{NewMarker}}
* [[uid]] - see also [[representative-hcard]]
* bank account [[bankaccount-brainstorming]], [[bankaccount-examples]]

=== solo pursuits ===
The following active exploratory discussions are primarily pursued by a single individual and thus have not generated widespread interest in the community yet.

* geo extensions ([[User:AndyMabbett|Andy Mabbett]])
** [[geo-elevation-examples]], [[geo-elevation-formats]] - extend geo for representing altitude
** [[geo-waypoint-examples]], [[geo-waypoint-formats]] - extend geo for representing routes and boundaries, using waypoints
** [[geo-extension-examples]], [[geo-extension-formats]], [[geo-extension-brainstorming]], [[geo-extension-strawman]] - extend geo for moons, other planets, etc.
* learning ([[learning-examples|examples]], [[learning-formats|formats]], [[learning-brainstorming|brainstorming]], [[learning-proposal|proposal]], [[learning-issues|issues]]) - a microformat for microlearning ([[User:KirkMcMurray|Kirk McMurray]])
* [[off|OFF]]
* [[xmdp-brainstorming|XMDP brainstorming]] (see also [[xmdp-faq]])

==Current==
The following exploratory discussions are less actively pursued, but may still be developed.

* citation [[citation|citation effort]], [[citation-examples|citation examples]], [[citation-formats|citation formats]], [[citation-brainstorming|citation brainstorming]], and [[citation-faq|citation FAQ]] ([[User:AndyMabbett|Andy Mabbett]])
* figures [[figure-examples|figure examples]], [[figure-formats]], [[figure-brainstorming|figure brainstorming]]
* genealogy [[genealogy-examples]], [[genealogy-formats|genealogy formats]] ([[User:Bob_Jonkman|Bob Jonkman]])
* listing / hListing [[hlisting-proposal|hListing proposal]], and [[hlisting-feedback|hListing feedback]]
** based on listing [[listing-examples|examples]], [[listing-formats|formats]], and [[listing-brainstorming|brainstorming]]
* [[mfo-examples|MFO examples]]
* task [[htask|task effort]], [[task-examples| task examples]], [[task-formats|task formats]], [[task-brainstorming|task brainstorming]], and [[task-faq|task FAQ]]

==Moribund==
The following exploratory discussions are believed moribund, or superseded; or are simply not being maintained due to the absence of the interested party or shortage of volunteer effort. Work may well resume in the future. Please feel free to move them to one of the above sections if you are interested in developing them, and append your name in parentheses, or move them to "Abandoned" or "Archived", if that is more appropriate.

*[[attention]]
* blog description [[blog-description-examples|blog description examples]]
* blog info [[blog-info-examples|blog info examples]]
* book [[book-examples|book examples]], [[book-formats|book formats]], and [[book-brainstorming|book brainstorming]]
* chat [[chat-examples|chat examples]], [[chat-formats|chat formats]], and [[chat-brainstorming|chat brainstorming]]
* code [[code-examples|code examples]], [[code-formats]], [[code-brainstorming|code brainstorming]]
* comment [[comment-problem|comment problem]], [[comment-examples|comment examples]], and [[comments-formats|comment formats]] (Some stuff needs to be extracted from [[comments-formats]])
* [[collection-description|collection description]] - for describing collections in libraries
* [[course-catalog]]; [[course-catalog-examples]]
* [[depend-examples]]: examples of dependency graphs, especially as they relate to software
* [[digital-signatures]]: incorporation of digital signatures in Microformatted data; ([[digitalsignature-examples|digital-signature examples]], [[digitalsignature-formats]], [[digitalsignature-brainstorming|digital-signatures brainstorming]])
* directions [[directions-examples|directions examples]]
* distributed conversation [[distributed-conversation|distributed conversation overview]], [[distributed-conversation-examples|distributed conversation examples]], [[distributed-conversation-formats|distributed conversation formats]], [[distributed-conversation-brainstorming|distributed conversation brainstorming]]
* [[downloads]] [[downloads-examples|downloads examples]], [[downloads-formats|downloads formats]], [[downloads-brainstorming|downloads brainstorming]]
* [[error-message]] [[error-message-examples|error message examples]], [[error-message-formats]], [[error-message-brainstorming|error message brainstorming]]
* file-format ([[file-format-examples|examples]], formats, brainstorming) - for the mark-up of file format information (size, type, codecs, bitrate, etc.) - should this be merged with [[downloads]] ?
* forms [[forms-examples|forms examples]]
* grouping ([[grouping-examples|examples]], [[grouping-formats|formats]], [[grouping-brainstorming|brainstorming]], [[grouping-proposal|proposal]]) - Metadata markup of items that should be grouped together.
* hash [[hash-examples|hash examples]] (see also [[downloads]])
* job listing [[job-listing-examples|job listing examples]], [[job-listing-formats]], [[job-listing-brainstorming|job listing brainstorming]]
* last modified [[last-modified-examples|last modified examples]], [[last-modified-formats|last modified formats]], and [[last-modified-brainstorming|last modified brainstorming]]
* meeting minutes [[meeting-minutes-examples|meeting minutes examples]], [[meeting-minutes-formats|meeting minutes formats]], and [[meeting-minutes-brainstorming|meeting minutes brainstorming]]
* metalink [[metalink-examples|metalink examples]]
* news [[news-examples|news examples]]
* [[operating-hours]]: [[operating-hours-examples]] ..of stores, restaurants, etc.
* [[page-summary]] [[page-summary-examples]], [[page-summary-formats]]
* [[payment]]
* [[product]] - [[product-examples]], [[product-formats]], [[product-brainstorming]].
* [[question-answer]], [[question-answer-examples]], [[question-answer-formats]], [[question-answer-brainstorming]]
* [[realestate-propertydetail]], [[realestate-propertydetail-examples]], [[realestate-propertydetail-formats]], [[realestate-propertydetail brainstorming]]
* requirements testing [[requirements-testing|requirements testing overview]], and [[requirements-testing-examples|requirements testing examples]]
* [[rest-examples|REST examples]] (see also [[rest]])
* search results [[search-results-example|search results example]]
* table [[table-examples|examples]]
* tagspeak [[tagspeak-examples|tagspeak examples]]
* tagcloud [[tagcloud-examples|tagcloud examples]], [[tagcloud-formats]], and [[tagcloud-brainstorming|tagcloud brainstorming]].
* transit table [[transit-table-examples|transit table examples]]
* [[widget]], [[widget-examples|widget examples]], [[widget-formats]], [[widget-brainstorming|widget brainstorming]]
* [[wiki-formats|wiki formats]]
* work of art [[work-of-art|work of art overview]], [[workofart-examples|work of art examples]], [[workofart-formats|work of art formats]], and [[workofart-brainstorming|work of art brainstorming]]

==Abandoned==
The following exploratory discussions are confirmed as abandoned:
*...

==Archive==

The following exploratory discussions resulted in a microformat, or have been superseded by later developments, but are kept here for historical interest:

* blog post [[blog-post-examples|examples]], [[blog-post-formats|blog post formats]], and [[blog-post-brainstorming|blog post brainstorming]] (yielded the [[hatom|hAtom]] draft)
* directory inclusion [[directory-inclusion-examples|directory inclusion examples]], [[directory-inclusion-formats|directory inclusion formats]]. (yielded the [[rel-directory]] microformat)
* location [[location-examples]], [[location-formats|location formats]]. (see also [[adr]], [[geo]], [[hcard|hCard]])
* resume [[resume-examples]], [[resume-formats|resume formats]], [[resume-brainstorming|resume brainstorming]] yielded the [[hresume|hResume]] draft.
* review [[review-examples|review examples]], and [[review-formats|review formats]] yielded the [[hreview|hReview]] draft

bankaccount-brainstorming

2008-01-05T19:58:53Z

Guillaume Lebleu: /* The Problem */

{{formatset|bankaccount}}
<h1>Bankaccount-Brainstorming</h1>

== The Problem ==
A microformat for account numbers would allow people to act on the data in a page and avoid the terrible consequences of getting a bank account number wrong!

== To be incorporated ==
* [[rel-payment]] for the links pointing on this sites.
* [[currency-proposal]] for bills
* [[uid]]: account numbers are identifiers

operating-hours-examples

2007-12-23T21:02:43Z

Guillaume Lebleu: /* Specific Examples from the Wild */

<h1>Operating Hours Examples</h1>

This page is for documenting real world examples of organizations (e.g. retail stores, restaurants, museums, offices) publishing operating hours. This page is a supplement to the [[operating-hours]] discussion.

__TOC__

= Discussion Participants =

== Editor ==
* [http://makedatamakesense.com/ Scott Reynen]

== Contributors ==
* [http://makedatamakesense.com/ Scott Reynen]
* [http://dragotown.com Nick Drago]

== Interested Folks ==

= Specific Examples from the Wild =

== Fry's Electronics ==

* [[http://www.frys-electronics-ads.com/frys-store-location.htm Website]]

<pre><nowiki>
Regular store hours for all Fry's Locations 
Monday through Friday: 8 AM - 9 PM 
Saturday: 9 AM - 9 PM 
Sunday: 9 AM - 7 PM 
</nowiki></pre>

== Hobby Lobby ==

* [[http://www.hobbylobby.com/site3/store/hours.cfm Website]]

<pre><nowiki>
<tr><TD COLSPAN=3 WIDTH=303 align="center"> <H1>WEEK DAYS</H1> MONDAY through SATURDAY </TD></tr>
<tr>
<TD WIDTH=115 align="center"> <H3>WEEK DAY</H3> </TD>
<TD WIDTH=87 align="center"> <H3>OPEN</H3> </TD>
<TD WIDTH=101 align="center"> <H3>CLOSE</H3> </TD>
</tr>
<tr>
<Th align="left">Monday </Th>
<Th align="center">9:00 am </Th>
<Th align="center">8:00 pm </Th>
</tr>
<tr>
<Th align="left">Tuesday </Th>
<Th align="center">9:00 am </Th>
<Th align="center">8:00 pm </Th>
</tr>
<tr>
<Th align="left">Wednesday </Th>
<Th align="center">9:00 am </Th>
<Th align="center">8:00 pm </Th>
</tr>
<tr>
<Th align="left">Thursday </Th>
<Th align="center">9:00 am </Th>
<Th align="center">8:00 pm </Th>
</tr>
<tr>
<Th align="left">Friday </Th>
<Th align="center">9:00 am </Th>
<Th align="center">8:00 pm </Th>
</tr>
<tr>
<Th align="left">Saturday </Th>
<Th align="center">9:00 am </Th>
<Th align="center">8:00 pm </Th>
</tr>
<tr><td> </td></tr>
<tr>
<TD COLSPAN=3 WIDTH=303 align="center"> <H3>ALL STORES CLOSED ON SUNDAY</H3> </TD>
</tr>
</nowiki></pre>

== US Embassy, Tokyo ==

* [[http://tokyo.usembassy.gov/fukuoka/wwwh2map.html Website]]

<pre><nowiki>
 Operating Hours: 9:00 a.m. - 4:00 p.m. Monday - Friday,
excluding <A HREF="http://japan.usembassy.gov/e/acs/tacs-holidays.html" TARGET="_blank" CLASS="new">Japanese and American holidays</A>. We are closed for lunch from
noon until 1:00 p.m.
 
</nowiki></pre>

== Yale University Dining Services ==

* [[http://www.yale.edu/dining/options/hours.html Website]]

<pre><nowiki>
<a name="commons"></a>Commons
Dining Room x 2-0455
<ul type="square">
<li class="txt">Hot Breakfast: 7:45 am-11:00 am, Monday
thru Friday</li>
<li class="txt">Lunch: 11:00 am-2:30pm, Monday thru
Friday</li>
<li class="txt">Limited Lunch Menu: 2:30 pm-5:00 pm,
Monday thru Thursday</li>
<li class="txt">Dinner: 5:00 pm-8:00 pm, Monday thru
Thursday</li>
<li class="txt">Limited Dinner Menu: 8:00 pm-9:00 pm,
Monday thru Thursday</li>
</ul>
</nowiki></pre>

== Best Buy Store Locater ==

* [[http://www.bestbuy.com/site/olspage.jsp?id=cat12092&type=page&_requestid=93763 Website]]

<pre><nowiki>
<script>titleCase('ITHACA NY')</script> (Store 384) 
<script>titleCase('40 CATHERWOOD RD')</script> 
<script>titleCase('ITHACA')</script>, <script>titleCase('NY')</script> <script>titleCase('14850-1056')</script>
 
Phone: 607-257-6824 

Hours: Mon-Sat 10:00am-9:00pm Sun 11:00am-7:00pm
 
This store also features: 
</nowiki></pre>

== NYSE Holidays & Hours ==

* [[http://www.nyse.com/about/newsevents/1176373643795.html Website]]

Note that this page also includes holidays during which the markets are not operating.

<pre>
The New York Stock Exchange, NYSE, is open from Monday through Friday 9:30 a.m. to 4:00 p.m. ET. 
NYSE, NYSE Arca, NYSE Bonds and NYSE Arca Options markets will observe the holidays below: 

</pre>

= See also =
* [[operating-hours]]

bankaccount-examples

2007-12-01T01:02:16Z

Guillaume Lebleu: Included translation of Bankleitzahl

<h1>Bank Account Examples</h1>

Per the microformats [[process]] this is an [[examples]] page documenting existing real world examples of bank account references published on the Web. Next steps are to research [[bankaccount-formats]] and then (only ''after'' that), proceed with [[bankaccount-brainstorming]]. Only URLs to actual bank account numbers/references please.

== Contributors ==

* Klaus Muller
* Guillaume Lebleu

== Examples ==

=== Amazon.de (Germany) ===

[http://www.amazon.de/gp/help/seller/shipping.html?ie=UTF8&seller=A11MRI5N4LBZ82#policies Amazon.de]

<pre>
 
Unsere deutsche Bankverbindung: 
 
Empire Merchandising GmbH 
Volksbank Darmstadt/Deutschland 
Bankleitzahl (BLZ) 508 900 00 
Konto-Nr. 1757814 

BIC: GENODEF1VBD 
IBAN: DE 0750 8900 0000 0175 7814 
 
</pre>

This bank account reference is composed of:
* Bank account name (i.e. the name of the bank account, typically the same as the name of the bank account owner)
* Name and partial address of the bank maintaining the account
* [http://de.wikipedia.org/wiki/Bankleitzahl Bankleitzahl]: literaly, number that leads to the bank. A number issued by the Bundesbank to a bank or one of its branches (i.e. to a bank account issuer). It is composed of:
** 3 digit identifying the local Bundesbank code (the first digit is the clearing region).
** 1 digit identifying the bank group (ex. savings bank, commercial bank, etc.)
** 4 digits identifying the bank/branch
* Actual account number issued by the bank
* BIC: a number issued by SWIFT to a bank or one of its branches (i.e. to a bank account number issuer). See [http://www.swift.com/biconline/ SWIFT BIConline]
* IBAN: this is actually a [http://www.ecbs.org/iban.htm standardized] country specific concatenation/serialization of various account informations that together guarantees the account number uniqueness worldwide for use in any transaction, international or not. Note that even though IBAN is globally unique, the BIC must be provided in financial messages. For Germany, the IBAN is composed of:
** country code
** 2 check digits
** Bankleitzahl
** Account number

=== neckermann.de (Germany) ===

A link cannot be provided but if you want to see the sample below, go to the Web site and click Impressum.

<pre>
Bankverbindung: neckermann.de GmbH, 60279 Frankfurt.
 Bayerische Landesbank, Kto. 50 55 400, BLZ 700 500 00
</pre>

=== Christchurch city (New Zealand) ===

http://www.ccc.govt.nz/QuickAnswers/BylawsLicensing/Miscellaneous/F3635.asp

=== EDPNet (Belgium) ===

http://en.wiki.edpnet.be/index.php/What_is_the_bank_account_number_of_EDPnet

=== csa.gov.uk (UK) ===

http://www.csa.gov.uk/en/employers/payment.asp

=== Birmingham.gov.uk ===

http://www.birmingham.gov.uk/GenerateContent?CONTENT_ITEM_ID=557&CONTENT_ITEM_TYPE=0&MENU_ID=301

=== Bank of America Web banking (not from the public Web) ===

<pre>
<A href="/cgi-bin/ias/15_LXhvFyxHfHakKPIj_BukEUpZkH_aOGHTJAKA39e163375/2/WelcomeControl?action=account_details&accountIndex=0" class=linknormal>

Checking-8723</A>
</pre>

Just putting this one here to show an example of obfuscated bank account number. The actual account identifier used by the server is "0" (in combination of the user session), which is really a transient identifier. Another, user-friendly, identifier is presented to the user composed of the last four digits of the account number and the type of the account.

=== Haas School (USA) ===

http://www.haas.berkeley.edu/EWMBA/finaid/BillingPayOptions#WireTransfer

<pre>
<blockquote>

 University's bank name: Bank of America, NA 
Bank routing number: 0260-0959-3 (wire transfer only) 
Bank account number: 0175380001 
Bank address: 1655 Grant Street; Concord, CA 94520 

Bank SWIFT code: BOFAUS 3N 
Bank CHIPS Address: 0959 
Beneficiary: Regents of the University of California 
Reference: The eight-digit UC Berkeley Student ID Number and student name. 
</blockquote>

</pre>

bankaccount-examples

2007-11-30T23:58:25Z

Guillaume Lebleu: /* Haas School (USA) */

<h1>Bank Account Examples</h1>

Per the microformats [[process]] this is an [[examples]] page documenting existing real world examples of bank account references published on the Web. Next steps are to research [[bankaccount-formats]] and then (only ''after'' that), proceed with [[bankaccount-brainstorming]]. Only URLs to actual bank account numbers/references please.

== Contributors ==

* Klaus Muller
* Guillaume Lebleu

== Examples ==

=== Amazon.de (Germany) ===

[http://www.amazon.de/gp/help/seller/shipping.html?ie=UTF8&seller=A11MRI5N4LBZ82#policies Amazon.de]

<pre>
 
Unsere deutsche Bankverbindung: 
 
Empire Merchandising GmbH 
Volksbank Darmstadt/Deutschland 
Bankleitzahl (BLZ) 508 900 00 
Konto-Nr. 1757814 

BIC: GENODEF1VBD 
IBAN: DE 0750 8900 0000 0175 7814 
 
</pre>

This bank account reference is composed of:
* Bank account name (i.e. the name of the bank account, typically the same as the name of the bank account owner)
* Name and partial address of the bank maintaining the account
* [http://de.wikipedia.org/wiki/Bankleitzahl Bankleitzahl]: a number issued by the Bundesbank to a bank or one of its branches (i.e. to a bank account issuer). It is composed of:
** 3 digit identifying the local Bundesbank code (the first digit is the clearing region).
** 1 digit identifying the bank group (ex. savings bank, commercial bank, etc.)
** 4 digits identifying the bank/branch
* Actual account number issued by the bank
* BIC: a number issued by SWIFT to a bank or one of its branches (i.e. to a bank account number issuer). See [http://www.swift.com/biconline/ SWIFT BIConline]
* IBAN: this is actually a [http://www.ecbs.org/iban.htm standardized] country specific concatenation/serialization of various account informations that together guarantees the account number uniqueness worldwide for use in any transaction, international or not. Note that even though IBAN is globally unique, the BIC must be provided in financial messages. For Germany, the IBAN is composed of:
** country code
** 2 check digits
** Bankleitzahl
** Account number

=== neckermann.de (Germany) ===

A link cannot be provided but if you want to see the sample below, go to the Web site and click Impressum.

<pre>
Bankverbindung: neckermann.de GmbH, 60279 Frankfurt.
 Bayerische Landesbank, Kto. 50 55 400, BLZ 700 500 00
</pre>

=== Christchurch city (New Zealand) ===

http://www.ccc.govt.nz/QuickAnswers/BylawsLicensing/Miscellaneous/F3635.asp

=== EDPNet (Belgium) ===

http://en.wiki.edpnet.be/index.php/What_is_the_bank_account_number_of_EDPnet

=== csa.gov.uk (UK) ===

http://www.csa.gov.uk/en/employers/payment.asp

=== Birmingham.gov.uk ===

http://www.birmingham.gov.uk/GenerateContent?CONTENT_ITEM_ID=557&CONTENT_ITEM_TYPE=0&MENU_ID=301

=== Bank of America Web banking (not from the public Web) ===

<pre>
<A href="/cgi-bin/ias/15_LXhvFyxHfHakKPIj_BukEUpZkH_aOGHTJAKA39e163375/2/WelcomeControl?action=account_details&accountIndex=0" class=linknormal>

Checking-8723</A>
</pre>

Just putting this one here to show an example of obfuscated bank account number. The actual account identifier used by the server is "0" (in combination of the user session), which is really a transient identifier. Another, user-friendly, identifier is presented to the user composed of the last four digits of the account number and the type of the account.

=== Haas School (USA) ===

http://www.haas.berkeley.edu/EWMBA/finaid/BillingPayOptions#WireTransfer

<pre>
<blockquote>

 University's bank name: Bank of America, NA 
Bank routing number: 0260-0959-3 (wire transfer only) 
Bank account number: 0175380001 
Bank address: 1655 Grant Street; Concord, CA 94520 

Bank SWIFT code: BOFAUS 3N 
Bank CHIPS Address: 0959 
Beneficiary: Regents of the University of California 
Reference: The eight-digit UC Berkeley Student ID Number and student name. 
</blockquote>

</pre>

bankaccount-examples

2007-11-30T23:56:16Z

Guillaume Lebleu: Added Haas School example header

<h1>Bank Account Examples</h1>

Per the microformats [[process]] this is an [[examples]] page documenting existing real world examples of bank account references published on the Web. Next steps are to research [[bankaccount-formats]] and then (only ''after'' that), proceed with [[bankaccount-brainstorming]]. Only URLs to actual bank account numbers/references please.

== Contributors ==

* Klaus Muller
* Guillaume Lebleu

== Examples ==

=== Amazon.de (Germany) ===

[http://www.amazon.de/gp/help/seller/shipping.html?ie=UTF8&seller=A11MRI5N4LBZ82#policies Amazon.de]

<pre>
 
Unsere deutsche Bankverbindung: 
 
Empire Merchandising GmbH 
Volksbank Darmstadt/Deutschland 
Bankleitzahl (BLZ) 508 900 00 
Konto-Nr. 1757814 

BIC: GENODEF1VBD 
IBAN: DE 0750 8900 0000 0175 7814 
 
</pre>

This bank account reference is composed of:
* Bank account name (i.e. the name of the bank account, typically the same as the name of the bank account owner)
* Name and partial address of the bank maintaining the account
* [http://de.wikipedia.org/wiki/Bankleitzahl Bankleitzahl]: a number issued by the Bundesbank to a bank or one of its branches (i.e. to a bank account issuer). It is composed of:
** 3 digit identifying the local Bundesbank code (the first digit is the clearing region).
** 1 digit identifying the bank group (ex. savings bank, commercial bank, etc.)
** 4 digits identifying the bank/branch
* Actual account number issued by the bank
* BIC: a number issued by SWIFT to a bank or one of its branches (i.e. to a bank account number issuer). See [http://www.swift.com/biconline/ SWIFT BIConline]
* IBAN: this is actually a [http://www.ecbs.org/iban.htm standardized] country specific concatenation/serialization of various account informations that together guarantees the account number uniqueness worldwide for use in any transaction, international or not. Note that even though IBAN is globally unique, the BIC must be provided in financial messages. For Germany, the IBAN is composed of:
** country code
** 2 check digits
** Bankleitzahl
** Account number

=== neckermann.de (Germany) ===

A link cannot be provided but if you want to see the sample below, go to the Web site and click Impressum.

<pre>
Bankverbindung: neckermann.de GmbH, 60279 Frankfurt.
 Bayerische Landesbank, Kto. 50 55 400, BLZ 700 500 00
</pre>

=== Christchurch city (New Zealand) ===

http://www.ccc.govt.nz/QuickAnswers/BylawsLicensing/Miscellaneous/F3635.asp

=== EDPNet (Belgium) ===

http://en.wiki.edpnet.be/index.php/What_is_the_bank_account_number_of_EDPnet

=== csa.gov.uk (UK) ===

http://www.csa.gov.uk/en/employers/payment.asp

=== Birmingham.gov.uk ===

http://www.birmingham.gov.uk/GenerateContent?CONTENT_ITEM_ID=557&CONTENT_ITEM_TYPE=0&MENU_ID=301

=== Bank of America Web banking (not from the public Web) ===

<pre>
<A href="/cgi-bin/ias/15_LXhvFyxHfHakKPIj_BukEUpZkH_aOGHTJAKA39e163375/2/WelcomeControl?action=account_details&accountIndex=0" class=linknormal>

Checking-8723</A>
</pre>

Just putting this one here to show an example of obfuscated bank account number. The actual account identifier used by the server is "0" (in combination of the user session), which is really a transient identifier. Another, user-friendly, identifier is presented to the user composed of the last four digits of the account number and the type of the account.

=== Haas School (USA) ===

bankaccount-examples

2007-11-30T23:47:56Z

Guillaume Lebleu: Corrected header

<h1>Bank Account Examples</h1>

Per the microformats [[process]] this is an [[examples]] page documenting existing real world examples of bank account references published on the Web. Next steps are to research [[bankaccount-formats]] and then (only ''after'' that), proceed with [[bankaccount-brainstorming]]. Only URLs to actual bank account numbers/references please.

== Contributors ==

* Klaus Muller
* Guillaume Lebleu

== Examples ==

=== Amazon.de (Germany) ===

[http://www.amazon.de/gp/help/seller/shipping.html?ie=UTF8&seller=A11MRI5N4LBZ82#policies Amazon.de]

<pre>
 
Unsere deutsche Bankverbindung: 
 
Empire Merchandising GmbH 
Volksbank Darmstadt/Deutschland 
Bankleitzahl (BLZ) 508 900 00 
Konto-Nr. 1757814 

BIC: GENODEF1VBD 
IBAN: DE 0750 8900 0000 0175 7814 
 
</pre>

This bank account reference is composed of:
* Bank account name (i.e. the name of the bank account, typically the same as the name of the bank account owner)
* Name and partial address of the bank maintaining the account
* [http://de.wikipedia.org/wiki/Bankleitzahl Bankleitzahl]: a number issued by the Bundesbank to a bank or one of its branches (i.e. to a bank account issuer). It is composed of:
** 3 digit identifying the local Bundesbank code (the first digit is the clearing region).
** 1 digit identifying the bank group (ex. savings bank, commercial bank, etc.)
** 4 digits identifying the bank/branch
* Actual account number issued by the bank
* BIC: a number issued by SWIFT to a bank or one of its branches (i.e. to a bank account number issuer). See [http://www.swift.com/biconline/ SWIFT BIConline]
* IBAN: this is actually a [http://www.ecbs.org/iban.htm standardized] country specific concatenation/serialization of various account informations that together guarantees the account number uniqueness worldwide for use in any transaction, international or not. Note that even though IBAN is globally unique, the BIC must be provided in financial messages. For Germany, the IBAN is composed of:
** country code
** 2 check digits
** Bankleitzahl
** Account number

=== neckermann.de (Germany) ===

A link cannot be provided but if you want to see the sample below, go to the Web site and click Impressum.

<pre>
Bankverbindung: neckermann.de GmbH, 60279 Frankfurt.
 Bayerische Landesbank, Kto. 50 55 400, BLZ 700 500 00
</pre>

=== Christchurch city (New Zealand) ===

http://www.ccc.govt.nz/QuickAnswers/BylawsLicensing/Miscellaneous/F3635.asp

=== EDPNet (Belgium) ===

http://en.wiki.edpnet.be/index.php/What_is_the_bank_account_number_of_EDPnet

=== csa.gov.uk (UK) ===

http://www.csa.gov.uk/en/employers/payment.asp

=== Birmingham.gov.uk ===

http://www.birmingham.gov.uk/GenerateContent?CONTENT_ITEM_ID=557&CONTENT_ITEM_TYPE=0&MENU_ID=301

=== Bank of America Web banking (not from the public Web) ===

<pre>
<A href="/cgi-bin/ias/15_LXhvFyxHfHakKPIj_BukEUpZkH_aOGHTJAKA39e163375/2/WelcomeControl?action=account_details&accountIndex=0" class=linknormal>

Checking-8723</A>
</pre>

Just putting this one here to show an example of obfuscated bank account number. The actual account identifier used by the server is "0" (in combination of the user session), which is really a transient identifier. Another, user-friendly, identifier is presented to the user composed of the last four digits of the account number and the type of the account.

bankaccount-examples

2007-11-30T04:47:15Z

Guillaume Lebleu: /* Examples */

<h1>Bank Account Examples</h1>

Per the microformats [[process]] this is an [[examples]] page documenting existing real world examples of bank account references published on the Web. Next steps are to research [[bankaccount-formats]] and then (only ''after'' that), proceed with [[bankaccount-brainstorming]]. Only URLs to actual bank account numbers/references please.

== Contributors ==

* Klaus Muller
* Guillaume Lebleu

== Examples ==

=== Amazon.de (Germany) ===

[http://www.amazon.de/gp/help/seller/shipping.html?ie=UTF8&seller=A11MRI5N4LBZ82#policies Amazon.de]

<pre>
 
Unsere deutsche Bankverbindung: 
 
Empire Merchandising GmbH 
Volksbank Darmstadt/Deutschland 
Bankleitzahl (BLZ) 508 900 00 
Konto-Nr. 1757814 

BIC: GENODEF1VBD 
IBAN: DE 0750 8900 0000 0175 7814 
 
</pre>

This bank account reference is composed of:
* Bank account name (i.e. the name of the bank account, typically the same as the name of the bank account owner)
* Name and partial address of the bank maintaining the account
* [http://de.wikipedia.org/wiki/Bankleitzahl Bankleitzahl]: a number issued by the Bundesbank to a bank or one of its branches (i.e. to a bank account issuer). It is composed of:
** 3 digit identifying the local Bundesbank code (the first digit is the clearing region).
** 1 digit identifying the bank group (ex. savings bank, commercial bank, etc.)
** 4 digits identifying the bank/branch
* Actual account number issued by the bank
* BIC: a number issued by SWIFT to a bank or one of its branches (i.e. to a bank account number issuer). See [http://www.swift.com/biconline/ SWIFT BIConline]
* IBAN: this is actually a [http://www.ecbs.org/iban.htm standardized] country specific concatenation/serialization of various account informations that together guarantees the account number uniqueness worldwide for use in any transaction, international or not. Note that even though IBAN is globally unique, the BIC must be provided in financial messages. For Germany, the IBAN is composed of:
** country code
** 2 check digits
** Bankleitzahl
** Account number

=== neckermann.de (Germany) ===

A link cannot be provided but if you want to see the sample below, go to the Web site and click Impressum.

<pre>
Bankverbindung: neckermann.de GmbH, 60279 Frankfurt.
 Bayerische Landesbank, Kto. 50 55 400, BLZ 700 500 00
</pre>

== Christchurch city (New Zealand) ===

http://www.ccc.govt.nz/QuickAnswers/BylawsLicensing/Miscellaneous/F3635.asp

=== EDPNet (Belgium) ===

http://en.wiki.edpnet.be/index.php/What_is_the_bank_account_number_of_EDPnet

=== csa.gov.uk (UK) ===

http://www.csa.gov.uk/en/employers/payment.asp

=== Birmingham.gov.uk ===

http://www.birmingham.gov.uk/GenerateContent?CONTENT_ITEM_ID=557&CONTENT_ITEM_TYPE=0&MENU_ID=301

=== Bank of America Web banking (not from the public Web) ===

<pre>
<A href="/cgi-bin/ias/15_LXhvFyxHfHakKPIj_BukEUpZkH_aOGHTJAKA39e163375/2/WelcomeControl?action=account_details&accountIndex=0" class=linknormal>

Checking-8723</A>
</pre>

Just putting this one here to show an example of obfuscated bank account number. The actual account identifier used by the server is "0" (in combination of the user session), which is really a transient identifier. Another, user-friendly, identifier is presented to the user composed of the last four digits of the account number and the type of the account.

bankaccount-examples

2007-11-30T04:08:05Z

Guillaume Lebleu: Initial page creation

currency-brainstorming

2007-09-29T17:14:33Z

Guillaume Lebleu: /* Taylor Cowan */

== 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.

:Good idea, but shouldn't a Microformat use existing markup for language attributes, eg.

:<pre><abbr class="currency" title="CAD" lang="en">$</abbr>5.00</pre>

:Reference [http://www.w3.org/TR/html4/struct/dirlang.html#h-8.1 w3.org: 8.1 Specifying the language of content: the lang attribute]
:[[User:Bob Jonkman|Bob Jonkman]] 22:26, 12 Oct 2006 (PDT)

=== Ciaran McNulty ===
The only microformat that I've noticed currency units in is [[hlisting-proposal|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"?]'''
**date - class (optional - for historic values only, 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")
**<s>equivalence - class (optional; conversion should be done by the user agent. Do we need this? Does it need a numeric value?)</s>

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>

====HTML Entities====

*The following currency entities exist:
**<code>¤</code> - <code>& curren;</code> - currency
**<code>¢</code> - <code>& cent;</code> - cent
**<code>£</code> - <code>& pound;</code> - pound
**<code>¥</code> - <code>& yen;</code> - yen
**<code>€</code> - <code>& euro;</code> - Euro

===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 elements containing the type and value classes.

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.

*The claimed "lack of interest" in dated amounts ignores the [[currency-examples|evidence that such figures are widely published on the web]]. Most of your preceding "why not"s ignore the [[abbr-design-pattern]]. [[User:AndyMabbett|Andy Mabbett]] 07:30, 2 Jan 2007 (PST)

==Taylor Cowan==

Pretending to forget all that we've know up till now about microformats, what if we just wanted a way for web page designers to make their currency amounts unambiguous with respect to currency denomination and amount?

"one hundred bucks"

<pre><abbr class="currency" title="USD100">one hundred bucks</abbr></pre>

$100 (CAD)

<pre><abbr class="currency" title="CAD100">$100</abbr></pre>

10 cents

<pre><abbr class="currency" title="USD0.10">ten cents</abbr></pre>

compare:

<pre>10 <abbr class="unit" title="cent"><abbr
class="currency" title="USD">cents</abbr></abbr></pre>

man Yen

<pre><abbr class="currency" title="JPY10,000">man Yen</abbr></pre>

So within the title, we've got ISO###.##

Then later on we wanted to apply one of those amounts to the "price" of an hlisting:

<pre><abbr class="currency price" title="USD100">one hundred bucks</abbr></pre>

==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]

==Related pages==
{{currency-related-pages}}

currency-brainstorming

2007-09-29T17:12:33Z

Guillaume Lebleu: /* Brainstorming */

== 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.

:Good idea, but shouldn't a Microformat use existing markup for language attributes, eg.

:<pre><abbr class="currency" title="CAD" lang="en">$</abbr>5.00</pre>

:Reference [http://www.w3.org/TR/html4/struct/dirlang.html#h-8.1 w3.org: 8.1 Specifying the language of content: the lang attribute]
:[[User:Bob Jonkman|Bob Jonkman]] 22:26, 12 Oct 2006 (PDT)

=== Ciaran McNulty ===
The only microformat that I've noticed currency units in is [[hlisting-proposal|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"?]'''
**date - class (optional - for historic values only, 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")
**<s>equivalence - class (optional; conversion should be done by the user agent. Do we need this? Does it need a numeric value?)</s>

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>

====HTML Entities====

*The following currency entities exist:
**<code>¤</code> - <code>& curren;</code> - currency
**<code>¢</code> - <code>& cent;</code> - cent
**<code>£</code> - <code>& pound;</code> - pound
**<code>¥</code> - <code>& yen;</code> - yen
**<code>€</code> - <code>& euro;</code> - Euro

===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 elements containing the type and value classes.

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.

*The claimed "lack of interest" in dated amounts ignores the [[currency-examples|evidence that such figures are widely published on the web]]. Most of your preceding "why not"s ignore the [[abbr-design-pattern]]. [[User:AndyMabbett|Andy Mabbett]] 07:30, 2 Jan 2007 (PST)

==Taylor Cowan==

==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]

==Related pages==
{{currency-related-pages}}

currency-examples

2006-12-16T20:09:09Z

Guillaume Lebleu: /* Real-World Examples */

= Currency Examples =
The following are real-world examples and brainstorming for marking up '''[[currency]]'''.

==The Problem==

The problem: how to explicitly specify a) that a figure/number relates to money; b) the currency of a stated figure; and c) the period in which that figure was current.

*The currency sign cannot be used reliably since the same sign (or symbol) may represent more than one currency. eg. $ is used for many different dollars (USD, AUD, CAD...) and even [http://en.wikipedia.org/wiki/Currency_sign#Examples other units like pesos].
*The language of the page is not sufficient to define the currency of prices in the page:
**More than one currency may be used by people who speak the same language.
**The page may be written in one language and still quote prices/figures in a different country's currency.
**Even if a country can be identified, more than one currency may be used in that country.

Converting currency figures is a reasonably easy problem to solve as indicated by the [[#Existing_Practices]]. However many automated conversion tools must make assumptions about the original figure's currency -- e.g. assuming a USD for all uses of $, or British Pounds for £ (which is also [http://en.wikipedia.org/wiki/Lira sometimes used to denote Lira]).

=== Currency Changes ===
I wish to expand on one of the points mentioned above: there might be two or more currencies in the same country: e.g. in Romania
* ROL - Romanian Lei [being phased out]
* RON - Romanian New Lei
* after Romania joins the EU, the RON will be replaced by Euro, too (not imediately, probably in 2-3 years)

Although the three letter code is different in this case, the currency is often given as ''Lei''. There are other countries, where similar examples exist/existed. The two currencies might have an identical name, yet they have 2 very different meanings. Usually there is a difference of 3-4 orders of magnitude between the old currency and the new currency.
[[discoleo]]

===Related problems===
"Amounts" in arbitrary units is a bit harder and necessary for several applications.

For example, consider the work that has been done on a recipe microformat.

[[recipe-examples]]

Though we haven't reached this problem yet in the research, I can see it
coming:

Say you wanted to create a "shopping list" application which you could tell which recipes you wanted to cook, and have it automatically total up all the various amounts of ingredients and give you the net amount of stuff you wanted to pick up.

It would need to be able to determine precise amounts/units of each ingredient. This might turn out to be like the currency problem, or it might be more complex, given the variety of units used in recipes, English vs. metric etc. That's a case that might need a microformat. We need more research and analysis to really justify it, but I can see it within the realm of probable possibility.

===Use of currency amounts in tables===

Representing currency amounts in a table format is very common. For instance, see [http://investor.google.com/fin_data.html Google Financials].

In this table representation, it does not make sense to provide the currency information for each cell. Instead, it should be provided once at the table, thead, tr, or th, level, and then a td may override the default value. This is very similar to the common practice of indicating the currency and formatting in plain english: "Numbers in thousands of dollars" in the table title/subtitle or legend.

The microformat for currency amounts should provide a way to represent a default currency for all children of a table, thead, tr, or th nodes.
The currency symbol/abbreviation should be optional in for elements defined as containing currency values/amounts, if a default currency has been defined in one of the ancestor elements.

==Contributors==
* [http://weblog.200ok.com.au/ Ben Buchanan] (proponent)
* Arve Bersvendsen
* [http://tantek.com/log/ Tantek Çelik]
* [http://steve.ganz.name/ Steve Ganz]
* Charles Iliya Krempeaux
*[[User:AndyMabbett|Andy Mabbett]] (2nd proponent)
* Ciaran McNulty
* Mike Stickel
* Ben Ward
* Guillaume Lebleu

== Real-World Examples ==
''Links to public web pages, either popular or insightful''

=== [http://www.skype.com/products/skypeout/ SkypeOut Pricing] ===

<pre>2.1 US cents/2.4 CAN cents per minute</pre> (on the Web page)

<pre>¢2.1 USD (or ¢2.4 CAD) per minute.</pre> (in the announcement email)

See also [[measure]]

=== [http://enterpriseforum.mit.edu/mindshare/startingup/dilution.html MIT Enterprise Forum ] ===

<pre>$1 million in equity</pre>

<pre>$2.50 a share</pre>

See also [[measure]]

=== [http://tonto.eia.doe.gov/oog/info/ngw/historical/2004/06_24/ngupdate.asp Energy Information Administration] ===

<pre>23 cents per barrel</pre>

Also in this [http://www.eia.doe.gov/emeu/international/oilprice.html page]:

<pre>(U.S. Cents per Gallon)</pre>

<pre>(Euros per Thousand Liters)</pre>

<pre>(U.S. Dollars per Gallon)</pre>

See also [[measure]]

=== [http://www.cbc.ca/money/story/2005/08/08/oil-050808.html CBCNews] ===

<pre>$63.94 US per barrel, up $1.63 US</pre>

=== [http://finance.google.com/finance?q=google&hl=en Google Finance] ===

The current price of a stock:

<pre>401.90</pre>

=== [http://www.ebay.com eBay] ===

eBay marks prices as "ebcPr". eBay c? Price.

<pre>
<td class="ebcPr">$11.70 $12.95 </td>
</pre>

=== [http://code.google.com/webstats/2005-12/classes.html Google] ===

The Google Web Authoring Statistics mentions that "price" is the 40th most used class name.

Something like:

<pre>
$39.99
</pre>

=== [http://us.mcafee.com/root/package.asp?pkgid=100 McAfee] ===
<pre>
$39.99 (USD)
</pre>

=== [http://www.amazon.com/gp/product/0764597582/sr=8-9/qid=1153301402/ref=sr_1_9/002-9103678-0608852?ie=UTF8 Amazon] ===

<pre><td class="price">$34.85</td></pre>

=== [https://secure.vmp.com/signup/adv_signup.php?locale=fr_CA Bell Canada in French Canadian] ===

<pre>Niveau de service Premium - 125 $*</pre>

Note the placement of the dollar sign AFTER the number.

=== [https://secure.vmp.com/signup/adv_signup.php?locale=en_US Bell Canada in US English] ===

<pre>Premium Service Level - $125*</pre>

===Historic prices===
*West Midland Bird Club:
**[http://www.westmidlandbirdclub.com/biblio/worcs.htm#MalvernHand West Midland Bird Club Bibliography] (Published prices of old books)
**[http://www.westmidlandbirdclub.com/reviews/rarer.htm West Midland Bird Club CD-ROM review] (price at time of review; since reduced)
**[http://www.westmidlandbirdclub.com/archive/jubilee-54.htm Silver Jubilee] (1954) - prices in text ("'''five shilling subscriptions'''", "'''10/-'''") shown in footnotes as "'''1 shilling = 5p'''" and "'''10/- = 10 shillings (50p)'''" respectively.
*[http://en.wikipedia.org/wiki/Bleak_House#Original_publication Wikipedia: Bleak House]
**"Like most Dickens novels, Bleak House was published in 19 monthly instalments, each containing 32 pages of text and two illustrations by Phiz. Each cost one shilling, except for the last, which was a double issue and cost two." Dates in the subsequent table range monthly from March 1852 - September 1853
*[http://en.wikipedia.org/wiki/1922_in_Germany#Inflation_and_Repercussions Wikpedia: 1922 in Germany]
**"Despite the ending of cash payments for the rest of 1922, the main cause of Germany's inability to pay, the steady depreciation of the mark, was ongoing. Towards the end of the year it assumed a disastrous rapidity. On August 1, the US Dollar still stood at 643 Marks to the Dollar and the British Pound at 2,850 Marks to the Pound. But on September 5 the dollar had already risen to 1,440 Marks and the pound to 6,525 Marks, and in December the pound was worth between 30,000 and 40,000 marks and the dollar between 7,000 and 9,000."
*[http://news.bbc.co.uk/1/hi/business/1096916.stm BBC News story dated 2 January, 2001]
**"A barrel of Brent crude for February delivery came within range of $25 a barrel on Tuesday before slipping to $24.35, a closing price 48 cents above Friday's closing price of $23.87. In New York, the price of Nymex (New York Merchantile Exchange) crude reached $27.40 a barrel before settling at $27.40, a gain of 41 cents or 1.5% on the day. Nymex oil prices in 2000 averaged $30.20 a barrel, the highest level since 1983, and well above the 1999 average of $19.25. Traders also saw support for the oil price from the Opec basket of seven crude oils which stood at $21.75 a barrell on 29 December 2000. That was the seventh day the price stayed below a preferred range of $22-$28 a barrell. Under an Opec price stability measure, output will be cut by 500,000 barrels a day if the basket price stay below $22 for more than 10 days."
*[http://news.bbc.co.uk/1/hi/uk/911569.stm BBC News story dated 5 September, 2000]
**"The Millennium Commission's decision to grant an extra £47m to the Dome has been widely condemned by MPs on various political hues."
*[http://www.jamaica-gleaner.com/pages/history/story0014.html Jamaica and the Great War]
**"in 1917 [...] unemployment was high and wages were low - men received 9 pence a day to cut cane."
*[http://www.wilkiecollins.demon.co.uk/coinage/coins.htm Money and Coinage in Victorian Britain]
*[http://www.margaretmorgan.com/wesley/state.html Macaulay on the State of England in 1685]
**"In 1661 the justices at Chelmsford had fixed the wages of the Essex labourer, who was not boarded, at six shillings in winter and seven in summer."
*[http://www.bbc.co.uk/ww2peopleswar/stories/74/a4095074.shtml BBC - WW2 People's War]
**"I left [school] at Easter 1938. As soon as I had left school, my Father insisted that I went to work for my Uncle. My wages were 5 shillings per week plus board & lodgings"
*[http://privatewww.essex.ac.uk/~alan/family/N-Money.html Relative Value of Sums of Money]

== Existing Practices ==

===Firefox Extension===
[http://viewmycurrency.wordpress.com/about/ Firefox Currency Converter - ViewMyCurrency]

Note: the [http://viewmycurrency.backpackit.com/pub/403081 current bug list] illustrates some problems of identifying currencies based on page content alone:
<blockquote>
<ul>
<li>All $ symbols are treated as USD Very annoying if you are Australian, Canadian etc. (Needs a new feature)</li>
<li>‘Euro 2006 Championship’ should not be converted.</li>
<li>...</li>
<li>Don’t convert CVS keywords . $Revision: 1.3 $ should not be treated as dollars.</li>
</ul>
</blockquote>

===Greasemonkey Scripts ===
[http://nybblelabs.org.uk/projects/exchequer Exchequer]

[http://6v8.gamboni.org/Greasemonkey-Yahoo-Finance.html Yahoo! Finance Currency Converter]

===Relevant Standards ===
[http://www.xe.com/iso4217.htm ISO 4217 Codes]

== See Also ==
* [[currency-brainstorming]]
**[[currency-brainstorming#Straw man proposal]]
* [[abbr-design-pattern]]

currency-examples

2006-12-16T20:08:37Z

Guillaume Lebleu: /* [http://www.skype.com/products/skypeout/ SkypeOut Pricing] */

= Currency Examples =
The following are real-world examples and brainstorming for marking up '''[[currency]]'''.

==The Problem==

The problem: how to explicitly specify a) that a figure/number relates to money; b) the currency of a stated figure; and c) the period in which that figure was current.

*The currency sign cannot be used reliably since the same sign (or symbol) may represent more than one currency. eg. $ is used for many different dollars (USD, AUD, CAD...) and even [http://en.wikipedia.org/wiki/Currency_sign#Examples other units like pesos].
*The language of the page is not sufficient to define the currency of prices in the page:
**More than one currency may be used by people who speak the same language.
**The page may be written in one language and still quote prices/figures in a different country's currency.
**Even if a country can be identified, more than one currency may be used in that country.

Converting currency figures is a reasonably easy problem to solve as indicated by the [[#Existing_Practices]]. However many automated conversion tools must make assumptions about the original figure's currency -- e.g. assuming a USD for all uses of $, or British Pounds for £ (which is also [http://en.wikipedia.org/wiki/Lira sometimes used to denote Lira]).

=== Currency Changes ===
I wish to expand on one of the points mentioned above: there might be two or more currencies in the same country: e.g. in Romania
* ROL - Romanian Lei [being phased out]
* RON - Romanian New Lei
* after Romania joins the EU, the RON will be replaced by Euro, too (not imediately, probably in 2-3 years)

Although the three letter code is different in this case, the currency is often given as ''Lei''. There are other countries, where similar examples exist/existed. The two currencies might have an identical name, yet they have 2 very different meanings. Usually there is a difference of 3-4 orders of magnitude between the old currency and the new currency.
[[discoleo]]

===Related problems===
"Amounts" in arbitrary units is a bit harder and necessary for several applications.

For example, consider the work that has been done on a recipe microformat.

[[recipe-examples]]

Though we haven't reached this problem yet in the research, I can see it
coming:

Say you wanted to create a "shopping list" application which you could tell which recipes you wanted to cook, and have it automatically total up all the various amounts of ingredients and give you the net amount of stuff you wanted to pick up.

It would need to be able to determine precise amounts/units of each ingredient. This might turn out to be like the currency problem, or it might be more complex, given the variety of units used in recipes, English vs. metric etc. That's a case that might need a microformat. We need more research and analysis to really justify it, but I can see it within the realm of probable possibility.

===Use of currency amounts in tables===

Representing currency amounts in a table format is very common. For instance, see [http://investor.google.com/fin_data.html Google Financials].

In this table representation, it does not make sense to provide the currency information for each cell. Instead, it should be provided once at the table, thead, tr, or th, level, and then a td may override the default value. This is very similar to the common practice of indicating the currency and formatting in plain english: "Numbers in thousands of dollars" in the table title/subtitle or legend.

The microformat for currency amounts should provide a way to represent a default currency for all children of a table, thead, tr, or th nodes.
The currency symbol/abbreviation should be optional in for elements defined as containing currency values/amounts, if a default currency has been defined in one of the ancestor elements.

==Contributors==
* [http://weblog.200ok.com.au/ Ben Buchanan] (proponent)
* Arve Bersvendsen
* [http://tantek.com/log/ Tantek Çelik]
* [http://steve.ganz.name/ Steve Ganz]
* Charles Iliya Krempeaux
*[[User:AndyMabbett|Andy Mabbett]] (2nd proponent)
* Ciaran McNulty
* Mike Stickel
* Ben Ward
* Guillaume Lebleu

== Real-World Examples ==
''Links to public web pages, either popular or insightful''

=== [http://www.skype.com/products/skypeout/ SkypeOut Pricing] ===

<pre>2.1 US cents/2.4 CAN cents per minute</pre> (on the Web page)

<pre>¢2.1 USD (or ¢2.4 CAD) per minute.</pre> (in the announcement email)

=== [http://enterpriseforum.mit.edu/mindshare/startingup/dilution.html MIT Enterprise Forum ] ===

<pre>$1 million in equity</pre>

<pre>$2.50 a share</pre>

See also [[measure]]

=== [http://tonto.eia.doe.gov/oog/info/ngw/historical/2004/06_24/ngupdate.asp Energy Information Administration] ===

<pre>23 cents per barrel</pre>

Also in this [http://www.eia.doe.gov/emeu/international/oilprice.html page]:

<pre>(U.S. Cents per Gallon)</pre>

<pre>(Euros per Thousand Liters)</pre>

<pre>(U.S. Dollars per Gallon)</pre>

See also [[measure]]

=== [http://www.cbc.ca/money/story/2005/08/08/oil-050808.html CBCNews] ===

<pre>$63.94 US per barrel, up $1.63 US</pre>

=== [http://finance.google.com/finance?q=google&hl=en Google Finance] ===

The current price of a stock:

<pre>401.90</pre>

=== [http://www.ebay.com eBay] ===

eBay marks prices as "ebcPr". eBay c? Price.

<pre>
<td class="ebcPr">$11.70 $12.95 </td>
</pre>

=== [http://code.google.com/webstats/2005-12/classes.html Google] ===

The Google Web Authoring Statistics mentions that "price" is the 40th most used class name.

Something like:

<pre>
$39.99
</pre>

=== [http://us.mcafee.com/root/package.asp?pkgid=100 McAfee] ===
<pre>
$39.99 (USD)
</pre>

=== [http://www.amazon.com/gp/product/0764597582/sr=8-9/qid=1153301402/ref=sr_1_9/002-9103678-0608852?ie=UTF8 Amazon] ===

<pre><td class="price">$34.85</td></pre>

=== [https://secure.vmp.com/signup/adv_signup.php?locale=fr_CA Bell Canada in French Canadian] ===

<pre>Niveau de service Premium - 125 $*</pre>

Note the placement of the dollar sign AFTER the number.

=== [https://secure.vmp.com/signup/adv_signup.php?locale=en_US Bell Canada in US English] ===

<pre>Premium Service Level - $125*</pre>

===Historic prices===
*West Midland Bird Club:
**[http://www.westmidlandbirdclub.com/biblio/worcs.htm#MalvernHand West Midland Bird Club Bibliography] (Published prices of old books)
**[http://www.westmidlandbirdclub.com/reviews/rarer.htm West Midland Bird Club CD-ROM review] (price at time of review; since reduced)
**[http://www.westmidlandbirdclub.com/archive/jubilee-54.htm Silver Jubilee] (1954) - prices in text ("'''five shilling subscriptions'''", "'''10/-'''") shown in footnotes as "'''1 shilling = 5p'''" and "'''10/- = 10 shillings (50p)'''" respectively.
*[http://en.wikipedia.org/wiki/Bleak_House#Original_publication Wikipedia: Bleak House]
**"Like most Dickens novels, Bleak House was published in 19 monthly instalments, each containing 32 pages of text and two illustrations by Phiz. Each cost one shilling, except for the last, which was a double issue and cost two." Dates in the subsequent table range monthly from March 1852 - September 1853
*[http://en.wikipedia.org/wiki/1922_in_Germany#Inflation_and_Repercussions Wikpedia: 1922 in Germany]
**"Despite the ending of cash payments for the rest of 1922, the main cause of Germany's inability to pay, the steady depreciation of the mark, was ongoing. Towards the end of the year it assumed a disastrous rapidity. On August 1, the US Dollar still stood at 643 Marks to the Dollar and the British Pound at 2,850 Marks to the Pound. But on September 5 the dollar had already risen to 1,440 Marks and the pound to 6,525 Marks, and in December the pound was worth between 30,000 and 40,000 marks and the dollar between 7,000 and 9,000."
*[http://news.bbc.co.uk/1/hi/business/1096916.stm BBC News story dated 2 January, 2001]
**"A barrel of Brent crude for February delivery came within range of $25 a barrel on Tuesday before slipping to $24.35, a closing price 48 cents above Friday's closing price of $23.87. In New York, the price of Nymex (New York Merchantile Exchange) crude reached $27.40 a barrel before settling at $27.40, a gain of 41 cents or 1.5% on the day. Nymex oil prices in 2000 averaged $30.20 a barrel, the highest level since 1983, and well above the 1999 average of $19.25. Traders also saw support for the oil price from the Opec basket of seven crude oils which stood at $21.75 a barrell on 29 December 2000. That was the seventh day the price stayed below a preferred range of $22-$28 a barrell. Under an Opec price stability measure, output will be cut by 500,000 barrels a day if the basket price stay below $22 for more than 10 days."
*[http://news.bbc.co.uk/1/hi/uk/911569.stm BBC News story dated 5 September, 2000]
**"The Millennium Commission's decision to grant an extra £47m to the Dome has been widely condemned by MPs on various political hues."
*[http://www.jamaica-gleaner.com/pages/history/story0014.html Jamaica and the Great War]
**"in 1917 [...] unemployment was high and wages were low - men received 9 pence a day to cut cane."
*[http://www.wilkiecollins.demon.co.uk/coinage/coins.htm Money and Coinage in Victorian Britain]
*[http://www.margaretmorgan.com/wesley/state.html Macaulay on the State of England in 1685]
**"In 1661 the justices at Chelmsford had fixed the wages of the Essex labourer, who was not boarded, at six shillings in winter and seven in summer."
*[http://www.bbc.co.uk/ww2peopleswar/stories/74/a4095074.shtml BBC - WW2 People's War]
**"I left [school] at Easter 1938. As soon as I had left school, my Father insisted that I went to work for my Uncle. My wages were 5 shillings per week plus board & lodgings"
*[http://privatewww.essex.ac.uk/~alan/family/N-Money.html Relative Value of Sums of Money]

== Existing Practices ==

===Firefox Extension===
[http://viewmycurrency.wordpress.com/about/ Firefox Currency Converter - ViewMyCurrency]

Note: the [http://viewmycurrency.backpackit.com/pub/403081 current bug list] illustrates some problems of identifying currencies based on page content alone:
<blockquote>
<ul>
<li>All $ symbols are treated as USD Very annoying if you are Australian, Canadian etc. (Needs a new feature)</li>
<li>‘Euro 2006 Championship’ should not be converted.</li>
<li>...</li>
<li>Don’t convert CVS keywords . $Revision: 1.3 $ should not be treated as dollars.</li>
</ul>
</blockquote>

===Greasemonkey Scripts ===
[http://nybblelabs.org.uk/projects/exchequer Exchequer]

[http://6v8.gamboni.org/Greasemonkey-Yahoo-Finance.html Yahoo! Finance Currency Converter]

===Relevant Standards ===
[http://www.xe.com/iso4217.htm ISO 4217 Codes]

== See Also ==
* [[currency-brainstorming]]
**[[currency-brainstorming#Straw man proposal]]
* [[abbr-design-pattern]]

currency-examples

2006-12-16T20:07:00Z

Guillaume Lebleu:

= Currency Examples =
The following are real-world examples and brainstorming for marking up '''[[currency]]'''.

==The Problem==

The problem: how to explicitly specify a) that a figure/number relates to money; b) the currency of a stated figure; and c) the period in which that figure was current.

*The currency sign cannot be used reliably since the same sign (or symbol) may represent more than one currency. eg. $ is used for many different dollars (USD, AUD, CAD...) and even [http://en.wikipedia.org/wiki/Currency_sign#Examples other units like pesos].
*The language of the page is not sufficient to define the currency of prices in the page:
**More than one currency may be used by people who speak the same language.
**The page may be written in one language and still quote prices/figures in a different country's currency.
**Even if a country can be identified, more than one currency may be used in that country.

Converting currency figures is a reasonably easy problem to solve as indicated by the [[#Existing_Practices]]. However many automated conversion tools must make assumptions about the original figure's currency -- e.g. assuming a USD for all uses of $, or British Pounds for £ (which is also [http://en.wikipedia.org/wiki/Lira sometimes used to denote Lira]).

=== Currency Changes ===
I wish to expand on one of the points mentioned above: there might be two or more currencies in the same country: e.g. in Romania
* ROL - Romanian Lei [being phased out]
* RON - Romanian New Lei
* after Romania joins the EU, the RON will be replaced by Euro, too (not imediately, probably in 2-3 years)

Although the three letter code is different in this case, the currency is often given as ''Lei''. There are other countries, where similar examples exist/existed. The two currencies might have an identical name, yet they have 2 very different meanings. Usually there is a difference of 3-4 orders of magnitude between the old currency and the new currency.
[[discoleo]]

===Related problems===
"Amounts" in arbitrary units is a bit harder and necessary for several applications.

For example, consider the work that has been done on a recipe microformat.

[[recipe-examples]]

Though we haven't reached this problem yet in the research, I can see it
coming:

Say you wanted to create a "shopping list" application which you could tell which recipes you wanted to cook, and have it automatically total up all the various amounts of ingredients and give you the net amount of stuff you wanted to pick up.

It would need to be able to determine precise amounts/units of each ingredient. This might turn out to be like the currency problem, or it might be more complex, given the variety of units used in recipes, English vs. metric etc. That's a case that might need a microformat. We need more research and analysis to really justify it, but I can see it within the realm of probable possibility.

===Use of currency amounts in tables===

Representing currency amounts in a table format is very common. For instance, see [http://investor.google.com/fin_data.html Google Financials].

In this table representation, it does not make sense to provide the currency information for each cell. Instead, it should be provided once at the table, thead, tr, or th, level, and then a td may override the default value. This is very similar to the common practice of indicating the currency and formatting in plain english: "Numbers in thousands of dollars" in the table title/subtitle or legend.

The microformat for currency amounts should provide a way to represent a default currency for all children of a table, thead, tr, or th nodes.
The currency symbol/abbreviation should be optional in for elements defined as containing currency values/amounts, if a default currency has been defined in one of the ancestor elements.

==Contributors==
* [http://weblog.200ok.com.au/ Ben Buchanan] (proponent)
* Arve Bersvendsen
* [http://tantek.com/log/ Tantek Çelik]
* [http://steve.ganz.name/ Steve Ganz]
* Charles Iliya Krempeaux
*[[User:AndyMabbett|Andy Mabbett]] (2nd proponent)
* Ciaran McNulty
* Mike Stickel
* Ben Ward
* Guillaume Lebleu

== Real-World Examples ==
''Links to public web pages, either popular or insightful''

=== [http://www.skype.com/products/skypeout/ SkypeOut Pricing] ===

=== [http://enterpriseforum.mit.edu/mindshare/startingup/dilution.html MIT Enterprise Forum ] ===

<pre>$1 million in equity</pre>

<pre>$2.50 a share</pre>

See also [[measure]]

=== [http://tonto.eia.doe.gov/oog/info/ngw/historical/2004/06_24/ngupdate.asp Energy Information Administration] ===

<pre>23 cents per barrel</pre>

Also in this [http://www.eia.doe.gov/emeu/international/oilprice.html page]:

<pre>(U.S. Cents per Gallon)</pre>

<pre>(Euros per Thousand Liters)</pre>

<pre>(U.S. Dollars per Gallon)</pre>

See also [[measure]]

=== [http://www.cbc.ca/money/story/2005/08/08/oil-050808.html CBCNews] ===

<pre>$63.94 US per barrel, up $1.63 US</pre>

=== [http://finance.google.com/finance?q=google&hl=en Google Finance] ===

The current price of a stock:

<pre>401.90</pre>

=== [http://www.ebay.com eBay] ===

eBay marks prices as "ebcPr". eBay c? Price.

<pre>
<td class="ebcPr">$11.70 $12.95 </td>
</pre>

=== [http://code.google.com/webstats/2005-12/classes.html Google] ===

The Google Web Authoring Statistics mentions that "price" is the 40th most used class name.

Something like:

<pre>
$39.99
</pre>

=== [http://us.mcafee.com/root/package.asp?pkgid=100 McAfee] ===
<pre>
$39.99 (USD)
</pre>

=== [http://www.amazon.com/gp/product/0764597582/sr=8-9/qid=1153301402/ref=sr_1_9/002-9103678-0608852?ie=UTF8 Amazon] ===

<pre><td class="price">$34.85</td></pre>

=== [https://secure.vmp.com/signup/adv_signup.php?locale=fr_CA Bell Canada in French Canadian] ===

<pre>Niveau de service Premium - 125 $*</pre>

Note the placement of the dollar sign AFTER the number.

=== [https://secure.vmp.com/signup/adv_signup.php?locale=en_US Bell Canada in US English] ===

<pre>Premium Service Level - $125*</pre>

===Historic prices===
*West Midland Bird Club:
**[http://www.westmidlandbirdclub.com/biblio/worcs.htm#MalvernHand West Midland Bird Club Bibliography] (Published prices of old books)
**[http://www.westmidlandbirdclub.com/reviews/rarer.htm West Midland Bird Club CD-ROM review] (price at time of review; since reduced)
**[http://www.westmidlandbirdclub.com/archive/jubilee-54.htm Silver Jubilee] (1954) - prices in text ("'''five shilling subscriptions'''", "'''10/-'''") shown in footnotes as "'''1 shilling = 5p'''" and "'''10/- = 10 shillings (50p)'''" respectively.
*[http://en.wikipedia.org/wiki/Bleak_House#Original_publication Wikipedia: Bleak House]
**"Like most Dickens novels, Bleak House was published in 19 monthly instalments, each containing 32 pages of text and two illustrations by Phiz. Each cost one shilling, except for the last, which was a double issue and cost two." Dates in the subsequent table range monthly from March 1852 - September 1853
*[http://en.wikipedia.org/wiki/1922_in_Germany#Inflation_and_Repercussions Wikpedia: 1922 in Germany]
**"Despite the ending of cash payments for the rest of 1922, the main cause of Germany's inability to pay, the steady depreciation of the mark, was ongoing. Towards the end of the year it assumed a disastrous rapidity. On August 1, the US Dollar still stood at 643 Marks to the Dollar and the British Pound at 2,850 Marks to the Pound. But on September 5 the dollar had already risen to 1,440 Marks and the pound to 6,525 Marks, and in December the pound was worth between 30,000 and 40,000 marks and the dollar between 7,000 and 9,000."
*[http://news.bbc.co.uk/1/hi/business/1096916.stm BBC News story dated 2 January, 2001]
**"A barrel of Brent crude for February delivery came within range of $25 a barrel on Tuesday before slipping to $24.35, a closing price 48 cents above Friday's closing price of $23.87. In New York, the price of Nymex (New York Merchantile Exchange) crude reached $27.40 a barrel before settling at $27.40, a gain of 41 cents or 1.5% on the day. Nymex oil prices in 2000 averaged $30.20 a barrel, the highest level since 1983, and well above the 1999 average of $19.25. Traders also saw support for the oil price from the Opec basket of seven crude oils which stood at $21.75 a barrell on 29 December 2000. That was the seventh day the price stayed below a preferred range of $22-$28 a barrell. Under an Opec price stability measure, output will be cut by 500,000 barrels a day if the basket price stay below $22 for more than 10 days."
*[http://news.bbc.co.uk/1/hi/uk/911569.stm BBC News story dated 5 September, 2000]
**"The Millennium Commission's decision to grant an extra £47m to the Dome has been widely condemned by MPs on various political hues."
*[http://www.jamaica-gleaner.com/pages/history/story0014.html Jamaica and the Great War]
**"in 1917 [...] unemployment was high and wages were low - men received 9 pence a day to cut cane."
*[http://www.wilkiecollins.demon.co.uk/coinage/coins.htm Money and Coinage in Victorian Britain]
*[http://www.margaretmorgan.com/wesley/state.html Macaulay on the State of England in 1685]
**"In 1661 the justices at Chelmsford had fixed the wages of the Essex labourer, who was not boarded, at six shillings in winter and seven in summer."
*[http://www.bbc.co.uk/ww2peopleswar/stories/74/a4095074.shtml BBC - WW2 People's War]
**"I left [school] at Easter 1938. As soon as I had left school, my Father insisted that I went to work for my Uncle. My wages were 5 shillings per week plus board & lodgings"
*[http://privatewww.essex.ac.uk/~alan/family/N-Money.html Relative Value of Sums of Money]

== Existing Practices ==

===Firefox Extension===
[http://viewmycurrency.wordpress.com/about/ Firefox Currency Converter - ViewMyCurrency]

Note: the [http://viewmycurrency.backpackit.com/pub/403081 current bug list] illustrates some problems of identifying currencies based on page content alone:
<blockquote>
<ul>
<li>All $ symbols are treated as USD Very annoying if you are Australian, Canadian etc. (Needs a new feature)</li>
<li>‘Euro 2006 Championship’ should not be converted.</li>
<li>...</li>
<li>Don’t convert CVS keywords . $Revision: 1.3 $ should not be treated as dollars.</li>
</ul>
</blockquote>

===Greasemonkey Scripts ===
[http://nybblelabs.org.uk/projects/exchequer Exchequer]

[http://6v8.gamboni.org/Greasemonkey-Yahoo-Finance.html Yahoo! Finance Currency Converter]

===Relevant Standards ===
[http://www.xe.com/iso4217.htm ISO 4217 Codes]

== See Also ==
* [[currency-brainstorming]]
**[[currency-brainstorming#Straw man proposal]]
* [[abbr-design-pattern]]

currency-proposal

2006-10-11T21:27:13Z

Guillaume Lebleu: /* Acknowledgements */

= Currency =

'''currency''' is a simple microformat for marking up money amounts, such as prices of products/services or financial facts.

== Introduction ==

Money amounts are one of the most widespread content found on the Web, but the lack of unambiguous representation of the currency they are expressed in, or the date that they relate to, makes comparison and matching of offerings online difficult.

== Acknowledgments ==

This proposal was written based on the contributions of several members of the community. Original brainstorming ideas and strawman proposal can be viewed at [[currency-brainstorming]] and [[currency-brainstorming#Andy_Mabbett]]

== Scope ==

This proposal limits its scope to:
* money amounts expressed in one officially issued coins and notes. This means it currently does not support money amounts expressed in terms of commodities or other liquefiable asset.
* money amounts expressed in one unit. This means that it currently does not support composite amounts such as "39 U.S. Dollars and 99 Cents".

== Features ==

* Reuse of widely used ISO 4217 for unambiguous encoding of currency types: ensures interoperability with many existing and emerging industry standards such as [http://www.ifxforum.org IFX], [http://www.acord.org ACORD], [http://www.xbrl.org XBRL] or [http://docs.oasis-open.org/ubl/cd-UBL-1.0/ UBL].
* Define currency once, use anywhere: allows currency units to be defined once and then referred to, instead of locally defined for each money amount, resulting in ease of readability for both human users and their user agents.
* Timestamping: money amounts have an optional date that allows user agents to translate a historical figure to an equivalent present amount.

=== Root Class Name ===

The root class name for a money amount is <code>money</code>.

=== Property List ===

* Required <code>amount</code>: can mark up a machine-readable numerical value with a <code>span</code>element or a string value with a <code>abbr</code> whose <code>title</code> attribute contains the machine-readable numerical value (See [[abbr-design-pattern]]).
* Optional <code>currency</code>, or reference to a currency (See [[include-pattern]]). Must markup a ISO 4217 compliant code or use the [[abbr-design-pattern]] to provide the equivalent ISO 4217 machine readable value to the marked up human-readable value.
* Optional <code>unit</code>, or reference to a unit of the currency (See [[include-pattern]]), for instance a "dollar" or "cent". This proposal does not specify how the unit must be marked up. This is the focus of the [[measure]] microformats. When not present, the unit is assumed to be the default unit for the given currency. For instance, "Dollar" for the U.S. currency.
* Optional <code>date</code> following the [[datetime-design-pattern]], specifies the date that must be used to evaluate the value of the currency unit used.

=== Examples ===

Simple in-line example with local definition of the currency unit: <abbr class="currency" title="USD">$</abbr>39.99

<pre>
<abbr class="currency" title="USD">$</abbr>39.99
</pre>

Text representation of the amount: <abbr class="amount">Thirty-nine</abbr> <abbr class="currency" title="USD">Dollars</abbr>

<pre>
<abbr class="amount" title="39">Thirty-nine</abbr> <abbr class="currency" title="USD">Dollars</abbr>
</pre>

Example using the <code>unit</code> class: 99<abbr class="unit">¢</abbr><abbr class="currency" title="USD"></abbr>

<pre>
99<abbr class="unit">¢</abbr><abbr class="currency" title="USD"></abbr>
</pre>

Table example with global definition of the currency:

<pre>
<table>
<tr><th>Price in <abbr id="u1" class="currency" title="USD">US$</abbr></th></tr>
<tr><td><div class="money">39.99<a href="#u1" class="include"></a></div></td></tr>
</table>
</pre>

currency-proposal

2006-10-11T21:26:39Z

Guillaume Lebleu: Added acknowledgements

= Currency =

'''currency''' is a simple microformat for marking up money amounts, such as prices of products/services or financial facts.

== Introduction ==

Money amounts are one of the most widespread content found on the Web, but the lack of unambiguous representation of the currency they are expressed in, or the date that they relate to, makes comparison and matching of offerings online difficult.

== Acknowledgements ==

This proposal was written based on the contributions of several members of the community. Original brainstorming ideas and strawman proposal can be viewed at [[currency-brainstorming]] and [[currency-brainstorming#Andy_Mabbett]]

== Scope ==

This proposal limits its scope to:
* money amounts expressed in one officially issued coins and notes. This means it currently does not support money amounts expressed in terms of commodities or other liquefiable asset.
* money amounts expressed in one unit. This means that it currently does not support composite amounts such as "39 U.S. Dollars and 99 Cents".

== Features ==

* Reuse of widely used ISO 4217 for unambiguous encoding of currency types: ensures interoperability with many existing and emerging industry standards such as [http://www.ifxforum.org IFX], [http://www.acord.org ACORD], [http://www.xbrl.org XBRL] or [http://docs.oasis-open.org/ubl/cd-UBL-1.0/ UBL].
* Define currency once, use anywhere: allows currency units to be defined once and then referred to, instead of locally defined for each money amount, resulting in ease of readability for both human users and their user agents.
* Timestamping: money amounts have an optional date that allows user agents to translate a historical figure to an equivalent present amount.

=== Root Class Name ===

The root class name for a money amount is <code>money</code>.

=== Property List ===

* Required <code>amount</code>: can mark up a machine-readable numerical value with a <code>span</code>element or a string value with a <code>abbr</code> whose <code>title</code> attribute contains the machine-readable numerical value (See [[abbr-design-pattern]]).
* Optional <code>currency</code>, or reference to a currency (See [[include-pattern]]). Must markup a ISO 4217 compliant code or use the [[abbr-design-pattern]] to provide the equivalent ISO 4217 machine readable value to the marked up human-readable value.
* Optional <code>unit</code>, or reference to a unit of the currency (See [[include-pattern]]), for instance a "dollar" or "cent". This proposal does not specify how the unit must be marked up. This is the focus of the [[measure]] microformats. When not present, the unit is assumed to be the default unit for the given currency. For instance, "Dollar" for the U.S. currency.
* Optional <code>date</code> following the [[datetime-design-pattern]], specifies the date that must be used to evaluate the value of the currency unit used.

=== Examples ===

Simple in-line example with local definition of the currency unit: <abbr class="currency" title="USD">$</abbr>39.99

<pre>
<abbr class="currency" title="USD">$</abbr>39.99
</pre>

Text representation of the amount: <abbr class="amount">Thirty-nine</abbr> <abbr class="currency" title="USD">Dollars</abbr>

<pre>
<abbr class="amount" title="39">Thirty-nine</abbr> <abbr class="currency" title="USD">Dollars</abbr>
</pre>

Example using the <code>unit</code> class: 99<abbr class="unit">¢</abbr><abbr class="currency" title="USD"></abbr>

<pre>
99<abbr class="unit">¢</abbr><abbr class="currency" title="USD"></abbr>
</pre>

Table example with global definition of the currency:

<pre>
<table>
<tr><th>Price in <abbr id="u1" class="currency" title="USD">US$</abbr></th></tr>
<tr><td><div class="money">39.99<a href="#u1" class="include"></a></div></td></tr>
</table>
</pre>

currency-proposal

2006-10-11T18:14:25Z

Guillaume Lebleu: /* Property List */

= Currency =

'''currency''' is a simple microformat for marking up money amounts, such as prices of products/services or financial facts.

== Introduction ==

Money amounts are one of the most widespread content found on the Web, but the lack of unambiguous representation of the currency they are expressed in, or the date that they relate to, makes comparison and matching of offerings online difficult.

== Scope ==

This proposal limits its scope to:
* money amounts expressed in one officially issued coins and notes. This means it currently does not support money amounts expressed in terms of commodities or other liquefiable asset.
* money amounts expressed in one unit. This means that it currently does not support composite amounts such as "39 U.S. Dollars and 99 Cents".

== Features ==

* Reuse of widely used ISO 4217 for unambiguous encoding of currency types: ensures interoperability with many existing and emerging industry standards such as [http://www.ifxforum.org IFX], [http://www.acord.org ACORD], [http://www.xbrl.org XBRL] or [http://docs.oasis-open.org/ubl/cd-UBL-1.0/ UBL].
* Define currency once, use anywhere: allows currency units to be defined once and then referred to, instead of locally defined for each money amount, resulting in ease of readability for both human users and their user agents.
* Timestamping: money amounts have an optional date that allows user agents to translate a historical figure to an equivalent present amount.

=== Root Class Name ===

The root class name for a money amount is <code>money</code>.

=== Property List ===

* Required <code>amount</code>: can mark up a machine-readable numerical value with a <code>span</code>element or a string value with a <code>abbr</code> whose <code>title</code> attribute contains the machine-readable numerical value (See [[abbr-design-pattern]]).
* Optional <code>currency</code>, or reference to a currency (See [[include-pattern]]). Must markup a ISO 4217 compliant code or use the [[abbr-design-pattern]] to provide the equivalent ISO 4217 machine readable value to the marked up human-readable value.
* Optional <code>unit</code>, or reference to a unit of the currency (See [[include-pattern]]), for instance a "dollar" or "cent". This proposal does not specify how the unit must be marked up. This is the focus of the [[measure]] microformats. When not present, the unit is assumed to be the default unit for the given currency. For instance, "Dollar" for the U.S. currency.
* Optional <code>date</code> following the [[datetime-design-pattern]], specifies the date that must be used to evaluate the value of the currency unit used.

=== Examples ===

Simple in-line example with local definition of the currency unit: <abbr class="currency" title="USD">$</abbr>39.99

<pre>
<abbr class="currency" title="USD">$</abbr>39.99
</pre>

Text representation of the amount: <abbr class="amount">Thirty-nine</abbr> <abbr class="currency" title="USD">Dollars</abbr>

<pre>
<abbr class="amount" title="39">Thirty-nine</abbr> <abbr class="currency" title="USD">Dollars</abbr>
</pre>

Example using the <code>unit</code> class: 99<abbr class="unit">¢</abbr><abbr class="currency" title="USD"></abbr>

<pre>
99<abbr class="unit">¢</abbr><abbr class="currency" title="USD"></abbr>
</pre>

Table example with global definition of the currency:

<pre>
<table>
<tr><th>Price in <abbr id="u1" class="currency" title="USD">US$</abbr></th></tr>
<tr><td><div class="money">39.99<a href="#u1" class="include"></a></div></td></tr>
</table>
</pre>

currency-proposal

2006-10-11T18:13:45Z

Guillaume Lebleu: Added example with "unit"

= Currency =

'''currency''' is a simple microformat for marking up money amounts, such as prices of products/services or financial facts.

== Introduction ==

Money amounts are one of the most widespread content found on the Web, but the lack of unambiguous representation of the currency they are expressed in, or the date that they relate to, makes comparison and matching of offerings online difficult.

== Scope ==

This proposal limits its scope to:
* money amounts expressed in one officially issued coins and notes. This means it currently does not support money amounts expressed in terms of commodities or other liquefiable asset.
* money amounts expressed in one unit. This means that it currently does not support composite amounts such as "39 U.S. Dollars and 99 Cents".

== Features ==

* Reuse of widely used ISO 4217 for unambiguous encoding of currency types: ensures interoperability with many existing and emerging industry standards such as [http://www.ifxforum.org IFX], [http://www.acord.org ACORD], [http://www.xbrl.org XBRL] or [http://docs.oasis-open.org/ubl/cd-UBL-1.0/ UBL].
* Define currency once, use anywhere: allows currency units to be defined once and then referred to, instead of locally defined for each money amount, resulting in ease of readability for both human users and their user agents.
* Timestamping: money amounts have an optional date that allows user agents to translate a historical figure to an equivalent present amount.

=== Root Class Name ===

The root class name for a money amount is <code>money</code>.

=== Property List ===

* Required <code>amount</code>: can mark up a machine-readable numerical value with a <code>span</code>element or a string value with a <code>abbr</code> whose <code>title</code> attribute contains the machine-readable numerical value (See [[abbr-design-pattern]]).
* Optional <code>currency</code>, or reference to a currency (See [[include-pattern]]). Must markup a ISO 4217 compliant code or use the [[abbr-design-pattern]] to provide the equivalent ISO 4217 machine readable value to the marked up human-readable value.
* Optional <code>unit</code>, or reference to a unit of the currency (See [[include-pattern]]), for instance a "dollar" or "cent". This proposal does not specify how the unit must be marked up. This is the focus of the [[measure]] microformats.
* Optional <code>date</code> following the [[datetime-design-pattern]], specifies the date that must be used to evaluate the value of the currency unit used.

=== Examples ===

Simple in-line example with local definition of the currency unit: <abbr class="currency" title="USD">$</abbr>39.99

<pre>
<abbr class="currency" title="USD">$</abbr>39.99
</pre>

Text representation of the amount: <abbr class="amount">Thirty-nine</abbr> <abbr class="currency" title="USD">Dollars</abbr>

<pre>
<abbr class="amount" title="39">Thirty-nine</abbr> <abbr class="currency" title="USD">Dollars</abbr>
</pre>

Example using the <code>unit</code> class: 99<abbr class="unit">¢</abbr><abbr class="currency" title="USD"></abbr>

<pre>
99<abbr class="unit">¢</abbr><abbr class="currency" title="USD"></abbr>
</pre>

Table example with global definition of the currency:

<pre>
<table>
<tr><th>Price in <abbr id="u1" class="currency" title="USD">US$</abbr></th></tr>
<tr><td><div class="money">39.99<a href="#u1" class="include"></a></div></td></tr>
</table>
</pre>

currency-proposal

2006-10-11T18:08:31Z

Guillaume Lebleu: /* Examples */

= Currency =

'''currency''' is a simple microformat for marking up money amounts, such as prices of products/services or financial facts.

== Introduction ==

Money amounts are one of the most widespread content found on the Web, but the lack of unambiguous representation of the currency they are expressed in, or the date that they relate to, makes comparison and matching of offerings online difficult.

== Scope ==

This proposal limits its scope to:
* money amounts expressed in one officially issued coins and notes. This means it currently does not support money amounts expressed in terms of commodities or other liquefiable asset.
* money amounts expressed in one unit. This means that it currently does not support composite amounts such as "39 U.S. Dollars and 99 Cents".

== Features ==

* Reuse of widely used ISO 4217 for unambiguous encoding of currency types: ensures interoperability with many existing and emerging industry standards such as [http://www.ifxforum.org IFX], [http://www.acord.org ACORD], [http://www.xbrl.org XBRL] or [http://docs.oasis-open.org/ubl/cd-UBL-1.0/ UBL].
* Define currency once, use anywhere: allows currency units to be defined once and then referred to, instead of locally defined for each money amount, resulting in ease of readability for both human users and their user agents.
* Timestamping: money amounts have an optional date that allows user agents to translate a historical figure to an equivalent present amount.

=== Root Class Name ===

The root class name for a money amount is <code>money</code>.

=== Property List ===

* Required <code>amount</code>: can mark up a machine-readable numerical value with a <code>span</code>element or a string value with a <code>abbr</code> whose <code>title</code> attribute contains the machine-readable numerical value (See [[abbr-design-pattern]]).
* Optional <code>currency</code>, or reference to a currency (See [[include-pattern]]). Must markup a ISO 4217 compliant code or use the [[abbr-design-pattern]] to provide the equivalent ISO 4217 machine readable value to the marked up human-readable value.
* Optional <code>unit</code>, or reference to a unit of the currency (See [[include-pattern]]), for instance a "dollar" or "cent". This proposal does not specify how the unit must be marked up. This is the focus of the [[measure]] microformats.
* Optional <code>date</code> following the [[datetime-design-pattern]], specifies the date that must be used to evaluate the value of the currency unit used.

=== Examples ===

Simple in-line example with local definition of the currency unit: <abbr class="currency" title="USD">$</abbr>39.99

<pre>
<abbr class="currency" title="USD">$</abbr>39.99
</pre>

Text representation of the amount: <abbr class="amount">Thirty-nine</abbr> <abbr class="currency" title="USD">Dollars</abbr>

<pre>
<abbr class="amount" title="39">Thirty-nine</abbr> <abbr class="currency" title="USD">Dollars</abbr>
</pre>

Table example with global definition of the currency:

<pre>
<table>
<tr><th>Price in <abbr id="u1" class="currency" title="USD">US$</abbr></th></tr>
<tr><td><div class="money">39.99<a href="#u1" class="include"></a></div></td></tr>
</table>
</pre>

currency-proposal

2006-10-11T18:07:20Z

Guillaume Lebleu: Precised the meaning of currency and unit

= Currency =

'''currency''' is a simple microformat for marking up money amounts, such as prices of products/services or financial facts.

== Introduction ==

Money amounts are one of the most widespread content found on the Web, but the lack of unambiguous representation of the currency they are expressed in, or the date that they relate to, makes comparison and matching of offerings online difficult.

== Scope ==

This proposal limits its scope to:
* money amounts expressed in one officially issued coins and notes. This means it currently does not support money amounts expressed in terms of commodities or other liquefiable asset.
* money amounts expressed in one unit. This means that it currently does not support composite amounts such as "39 U.S. Dollars and 99 Cents".

== Features ==

* Reuse of widely used ISO 4217 for unambiguous encoding of currency types: ensures interoperability with many existing and emerging industry standards such as [http://www.ifxforum.org IFX], [http://www.acord.org ACORD], [http://www.xbrl.org XBRL] or [http://docs.oasis-open.org/ubl/cd-UBL-1.0/ UBL].
* Define currency once, use anywhere: allows currency units to be defined once and then referred to, instead of locally defined for each money amount, resulting in ease of readability for both human users and their user agents.
* Timestamping: money amounts have an optional date that allows user agents to translate a historical figure to an equivalent present amount.

=== Root Class Name ===

The root class name for a money amount is <code>money</code>.

=== Property List ===

* Required <code>amount</code>: can mark up a machine-readable numerical value with a <code>span</code>element or a string value with a <code>abbr</code> whose <code>title</code> attribute contains the machine-readable numerical value (See [[abbr-design-pattern]]).
* Optional <code>currency</code>, or reference to a currency (See [[include-pattern]]). Must markup a ISO 4217 compliant code or use the [[abbr-design-pattern]] to provide the equivalent ISO 4217 machine readable value to the marked up human-readable value.
* Optional <code>unit</code>, or reference to a unit of the currency (See [[include-pattern]]), for instance a "dollar" or "cent". This proposal does not specify how the unit must be marked up. This is the focus of the [[measure]] microformats.
* Optional <code>date</code> following the [[datetime-design-pattern]], specifies the date that must be used to evaluate the value of the currency unit used.

=== Examples ===

Simple in-line example with local definition of the currency unit: <abbr class="currency unit" title="USD">$</abbr>39.99

<pre>
<abbr class="currency unit" title="USD">$</abbr>39.99
</pre>

Text representation of the amount: <abbr class="amount">Thirty-nine</abbr> <abbr class="currency unit" title="USD">Dollars</abbr>

<pre>
<abbr class="amount" title="39">Thirty-nine</abbr> <abbr class="currency unit" title="USD">Dollars</abbr>
</pre>

Table example with global definition of the currency unit:

<pre>
<table>
<tr><th>Price in <abbr id="u1" class="currency unit" title="USD">US$</abbr></th></tr>
<tr><td><div class="money">39.99<a href="#u1" class="include"></a></div></td></tr>
</table>
</pre>

currency-proposal

2006-10-11T04:50:53Z

Guillaume Lebleu: Added feature/benefit

= Currency =

'''currency''' is a simple microformat for marking up money amounts, such as prices of products/services or financial facts.

== Introduction ==

Money amounts are one of the most widespread content found on the Web, but the lack of unambiguous representation of the currency they are expressed in, or the date that they relate to, makes comparison and matching of offerings online difficult.

== Scope ==

This proposal limits its scope to:
* money amounts expressed in one officially issued coins and notes. This means it currently does not support money amounts expressed in terms of commodities or other liquefiable asset.
* money amounts expressed in one unit. This means that it currently does not support composite amounts such as "39 U.S. Dollars and 99 Cents".

== Features ==

* Reuse of widely used ISO 4217 for unambiguous encoding of currency types: ensures interoperability with many existing and emerging industry standards such as [http://www.ifxforum.org IFX], [http://www.acord.org ACORD], [http://www.xbrl.org XBRL] or [http://docs.oasis-open.org/ubl/cd-UBL-1.0/ UBL].
* Define currency once, use anywhere: allows currency units to be defined once and then referred to, instead of locally defined for each money amount, resulting in ease of readability for both human users and their user agents.
* Timestamping: money amounts have an optional date that allows user agents to translate a historical figure to an equivalent present amount.

=== Root Class Name ===

The root class name for a money amount is <code>money</code>.

=== Property List ===

* Required <code>amount</code>: can mark up a machine-readable numerical value with a <code>span</code>element or a string value with a <code>abbr</code> whose <code>title</code> attribute contains the machine-readable numerical value (See [[abbr-design-pattern]]).
* Optional <code>currency unit</code>, or reference to a currency unit (See [[include-pattern]]). Must contain a ISO 4217 compliant code.
* Optional <code>date</code> following the [[datetime-design-pattern]], specifies the date that must be used to evaluate the value of the currency unit used.

=== Examples ===

Simple in-line example with local definition of the currency unit: <abbr class="currency unit" title="USD">$</abbr>39.99

<pre>
<abbr class="currency unit" title="USD">$</abbr>39.99
</pre>

Text representation of the amount: <abbr class="amount">Thirty-nine</abbr> <abbr class="currency unit" title="USD">Dollars</abbr>

<pre>
<abbr class="amount" title="39">Thirty-nine</abbr> <abbr class="currency unit" title="USD">Dollars</abbr>
</pre>

Table example with global definition of the currency unit:

<pre>
<table>
<tr><th>Price in <abbr id="u1" class="currency unit" title="USD">US$</abbr></th></tr>
<tr><td><div class="money">39.99<a href="#u1" class="include"></a></div></td></tr>
</table>
</pre>

currency

2006-10-11T04:46:56Z

Guillaume Lebleu: /* Contributors */

= currency microformat efforts =

==Introduction==

All over the web, we see amounts of money, most usually as prices on eCommerce sites, but also in other contexts - salaries in job offers, fines mentioned in news reports and prices in product reviews, for example.

Wouldn't it be useful to be able to have them converted to your local currency, easily and quickly? Or to see the modern equivalent of an historical figure?

Those are just two of the things which a currency microformat might do for you.

==Related microformats==

The following is a non-exhaustive lists of microformats which might include an amount of money as a data item:

*[[job-listing]]
*[[hlisting]]
*[[hReview]]
*[[hresume]]

==Contributors==
* [http://weblog.200ok.com.au/ Ben Buchanan] (original proponent)
*[[User:AndyMabbett|Andy Mabbett]] (second proponent)
* Guillaume Lebleu

==See also==
Work in progress:

* [[currency-examples]]
* [[currency-formats]]
* [[currency-brainstorming]]
* [[currency-proposal]]

currency

2006-10-11T04:46:31Z

Guillaume Lebleu: Added link to currency proposal

= currency microformat efforts =

==Introduction==

All over the web, we see amounts of money, most usually as prices on eCommerce sites, but also in other contexts - salaries in job offers, fines mentioned in news reports and prices in product reviews, for example.

Wouldn't it be useful to be able to have them converted to your local currency, easily and quickly? Or to see the modern equivalent of an historical figure?

Those are just two of the things which a currency microformat might do for you.

==Related microformats==

The following is a non-exhaustive lists of microformats which might include an amount of money as a data item:

*[[job-listing]]
*[[hlisting]]
*[[hReview]]
*[[hresume]]

==Contributors==
* [http://weblog.200ok.com.au/ Ben Buchanan] (original proponent)
*[[User:AndyMabbett|Andy Mabbett]] (second proponent)

==See also==
Work in progress:

* [[currency-examples]]
* [[currency-formats]]
* [[currency-brainstorming]]
* [[currency-proposal]]

currency-proposal

2006-10-11T04:45:45Z

Guillaume Lebleu: Initial version

measure-brainstorming

2006-10-11T02:15:37Z

Guillaume Lebleu: Comments on Bogdan's notes

= Measure Microformat Brainstorming =

This page collects ideas on how to use semantic XHTML to represent unambiguously [[measure]]s.

== Guillaume Lebleu ==

Basic example with elementary unit using the abbr pattern and the UNECE code (see [[measure-formats]])

<pre>
5 <abbr class="unit" title="FOT">Feet</abbr>
</pre>

Optional "value" could be useful in some cases, for instance when the value is provided in plain text:

<pre>
<abbr class="value" title="5">Five</abbr> <abbr class="unit" title="FOT">Feet</abbr>
</pre>

==Andy Mabbett==
This Firefox extension may be of interest. Note, though, that it's been criticised for having a "nag" screen: [https://addons.mozilla.org/firefox/2286/ Converter] [[User:AndyMabbett|AndyMabbett]] 15:32, 3 Oct 2006 (PDT)

:This is the author of that extension. I don't want to go much into this, but I just want to clarify this briefly. The part with the nag screen is wrong on two counts: (1) that dialog isn't there anymore, and (2) even if it was there, you only needed to read a paragraph and click a button to make it go away ''forever'' -- but you don't have to take my word for it, install it for yourselves and see. Andy's report is accurate however -- the extension '''''was''''' criticized for that dialog (that's what you get from your free extension's users when you ask for 15 seconds of their time in return for hundreds of hours of your time). --[[User:BogdanStancescu|BogdanStancescu]] 09:35, 9 Oct 2006 (PDT)

==Bogdan Stăncescu==
Here are my findings related to automatic parsing of measurements on web pages while developing the [http://converter.mozdev.org Converter] extension. Please ask away if you want me to go into more detail on any of the topics -- I'm not sure which of my experiences are relevant to microformats, so I'm going to give you an overview of my conclusions.

By the way of an introduction, the Converter is a Firefox extension which tries to convert all measurements it finds in any web page to their Imperial or metric counterpart (e.g. Fahrenheit to Celsius, and Celsius to Fahrenheit; meters to feet and feet to meters). There are two steps to the conversion process: (1) identifying the measurements in the page, and (2) converting them. As expected, the conversion part is trivial, at least conceptually. The parsing is the tricky bit, and that's also where the Converter's challenges also become relevant for microformats.

Here are the main challenges I have encountered while writing the Converter:

;Presentation standardization: The first, biggest and most obvious challenge is lack of almost any ''de facto'' standardization in respect to data presentation. What I mean is that although the units themselves are more or less standardized (more on that later), they are ''presented'' in various ways within web pages. Take these examples: "50 foot monster", "50 ft monster", "50 feet monster", "50-foot monster", "50-feet monster" -- and my personal favorite, "fifty-foot monster" (more on this later);

:Note that using a microformat using in particular the [[abbr-design-pattern]] would make each of these examples less ambiguous if not unambiguous. See below --[[User:Guillaume_Lebleu|Guillaume_Lebleu]]:

<pre>
50<abbr class="unit" title="FOT">foot</abbr> monster
</pre>

<pre>
50<abbr class="unit" title="FOT">ft</abbr> monster
</pre>

<pre>
50-<abbr class="unit" title="FOT">foot</abbr> monster
</pre>

<pre>
50<abbr class="unit" title="FOT">feet</abbr> monster
</pre>

<pre>
<abbr class="value" title="50">fifty</abbr><abbr class="unit" title="FOT">foot</abbr> monster
</pre>

;Unit standardization: I live in Europe, where I've always used the metric system. As such, this probably was a much bigger nasty surprise for me than it is for a user of the Imperial/U.S. Customary system: in the Imperial system, the units themselves vary depending on where you are -- miles, pints, and a whole lot of other units come in many different flavors, but they're all written the same in regular usage;

;Language: "1 meter" vs. "1 metre" is a reasonable difference -- but non-SI units are usually translated. Even some SI units have different plurals, depending on the language, although in theory SI units are actually denoted by ''symbols'', not "words", as to make them non-translatable, and truly international (hence the name of the SI). I haven't really given much thought to a solution towards parsing these, because I find it overwhelming for the time.

;The sheer number of units: surprisingly, most people don't realize just how many units we humans have invented. Just take a look here: [http://www.asknumbers.com/ asknumbers.com] -- see how many categories there are? Now click on Flow Rate -- a non-ubiquitous type of measurement. Three sub-categories only for flow rates! Now click on Volume Flow Rate and take a look at the number of units in those lists. Remember, those are just in one of the three categories for flow rate! The UNECE standard mentioned in the [[measure-formats#Measure_Formats|measure formats]] page is useful to define just that -- a ''standard'' set of units. But in practice there are a lot more being used out there.

:Do you have examples from the Web (a URL) of non-UNECE units. One possibility would be to provide the ability for a unit to be defined as a division of products of other units. This is consistent with the [[measure-formats#Systeme_International]], which defines 7 base units and all other units as derived units (of course some units, even though they are derived are much easily represented as simple ones). This is what XBRL has done for financial/accounting/reporting. See [[currency-formats#XBRL]] and theorical example (ampere acre per second) below --[[User:Guillaume_Lebleu|Guillaume_Lebleu]]:

<pre>

<abbr class="unit" title="AMP">Ampere</abbr> <abbr class="unit" title="ACR">acre</abbr> per <abbr class="unit" title="SEC">second</abbr>

</pre>

That's all I can think of as major hurdles right now. If I remember anything else, I'll post here. Please do give me feedback here if you want to ask more about any of the topics I touched above, or if you have other questions I might be able to reply to. --[[User:BogdanStancescu|BogdanStancescu]] 12:08, 9 Oct 2006 (PDT)

currency-formats

2006-10-09T21:26:10Z

Guillaume Lebleu: /* XBRL */

= Currency formats prior art =

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

==Formats==

===UBL===

"[http://docs.oasis-open.org/ubl/cd-UBL-1.0/ UBL] is designed to provide a universally understood and recognized commercial syntax for legally binding business documents and to operate within a standard business framework such as ISO 15000 (ebXML) to provide a complete, standards-based infrastructure that can extend the benefits of existing EDI systems to businesses of all sizes."

UBL uses the following semantics for currency amounts:
*Amount (enclosed the value)
**amountCurrencyCodeListVersionID (ex. "0.3") - no longer used in 2.0
**amountCurrencyID (ex. "USD")

In addition, UBL uses the following semantics to specify a price for a product/service:
*Price
**PriceAmount qualified with a currencyID,
**BaseQuantity (usually 1) qualified with a unitCode.

So, according to UBL at least, a base quantity is an integral part of a price.

===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>
GBP
</pre>

Square feet (as simple unit)

<pre>
sqrft
</pre>

Square feet (as complex unit)

<pre>
sqrft*sqrft
</pre>

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

<pre>
EUR/shares
</pre>

100 UK pounds (with referred-to unit using the [[include-pattern]])

<pre>
100<a href="#u1" class="include"/>
</pre>

100 UK pounds (with locally defined unit)

<pre>
100 GBP
</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]]

include-pattern

2006-10-09T21:23:13Z

Guillaume Lebleu: /* Specifications Using */

<h1> include pattern </h1>

Initially developed as part of [[resume-brainstorming]], it has become clear from actual microformats markup experience with real world sites, that several microformats (e.g. [[hresume|hResume]], [[hreview|hReview]], [[hatom|hAtom]] etc.) need a mechanism to include a portion of data from area of a page into another area of a page. This page documents this pattern for re-use in those microformats and any others that need this feature.

; Author: Tantek Çelik

__TOC__

== Background ==

In [[hresume|hResume]], we needed the ability to include the name from the hCard at the top of the resume for a person into their hCards in the middle of the resume which represented each of their job hCards (job title, organization name, address etc.), and thus developed the [http://microformats.org/wiki/resume-brainstorming#hCard_reference_via_object hCard reference via object technique].

== class name "include" ==

In order to make this more explicit (helps forward compatibility for parsers), we are adding the class name "include" on the object element to indicate that that object refers to a subtree which should be included in its place by microformat parsers.

'''Proposal 1:''' Allow the use of <nowiki><a href class="include"></nowiki> as a secondary include-pattern mechanism, due to some browsers mishandling the object include-pattern. See [[include-pattern-feedback]] for details.

== object include example ==

Here is an example of an [[hcard|hCard]] you could have at the top of a page, shown here also as a verbose hCard for purposes of illustration that the reference may be to a subtree, not just a text node:

<pre><nowiki>


James Levine


</nowiki></pre>

Somewhere else on the page, you could have another hCard which would re-use that "fn n" content from the first hCard:

<pre><nowiki>

<object data="#j" class="include"></object>
SimplyHired
Microformat Brainstormer

</nowiki></pre>

Thus a microformat parser would treat the above as follows, with the object include completely replaced by the subtree that it references:

<pre><nowiki>


James Levine

SimplyHired
Microformat Brainstormer

</nowiki></pre>

This method of hCard property indirection via an object element can apply to any/all properties in class-based microformats.

Note 1: '''the object data attribute MUST be a local ID reference.''' External references (which would require a consuming application to load an external resource) are currently not supported by this method.

Note 2: To avoid unsightly messes in Safari, you should include the following style rule in a style sheet for the page:
<pre><nowiki>
object.include { width:0; height:0 }
</nowiki></pre>

Note 3: To prevent infinite loops, if a class="include" refers to itself or an ancestor in the parse tree, then it is ignored and has no effect on the parser.

== hyperlink include example ==

Per the proposal 1 above, here is how you would code the above object include example using the <nowiki><a href></nowiki> tag.

<pre><nowiki>

<a href="#j" class="include"></a>
SimplyHired
Microformat Brainstormer

</nowiki></pre>

Changes:
# a open/close tag instead of object open/close tag
# href attribute instead of data attribute
# ... that's it. only 2 changes.

And just as in the object include example, the end effective result to the parser is the same, and the same '''Notes''' apply.

<pre><nowiki>


James Levine

SimplyHired
Microformat Brainstormer

</nowiki></pre>

== Acknowledgments ==

Thanks to discussions and brainstorms with a bunch of folks: Ryan King, James Levine, the whole crowd at the [http://mashupcamp.com/index.cgi?HAtomFinalization Microformats specifications working session] at MashupCamp, Brian Suda, Scott Reynen, Drew McLellan.

== Specifications Using ==
* [[hresume|hResume]]
* [[hreview|hReview]]

=== Considering ===
* [[hatom|hAtom]]
* [[hcalendar|hCalendar]]
* [[hcard|hCard]]
* [[currency]]
* [[measure]]

== Implementations ==
* X2V implements the [[include-pattern]] when parsing [[hcard|hCards]] and [[hcalendar|hCalendars]] for both object.include and a.include.

== References ==

=== Normative ===
* HTML 4.01
* XHTML 1.0

=== Informative ===
* [[hcard|hCard]]

=== Related ===

* [http://www.mnot.net/javascript/hinclude.html Introducing HInclude] by Mark Nottingham.
** HInclude is a markup extension + javascript library for including *external* files into an XHTML document.

== Discussions ==
* Feedback is encouraged on the [[include-pattern-feedback]] page.
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

=== Q&A ===
* If you have any questions about include-pattern, check the [[include-pattern-faq|include-pattern FAQ]], and if you don't find answers, add your questions to the end of the page!

=== Issues ===
* Please add any issues with the specification to the separate [[include-pattern-issues|include-pattern issues]] document.

include-pattern

2006-10-09T21:21:02Z

Guillaume Lebleu: /* Specifications Using */

<h1> include pattern </h1>

Initially developed as part of [[resume-brainstorming]], it has become clear from actual microformats markup experience with real world sites, that several microformats (e.g. [[hresume|hResume]], [[hreview|hReview]], [[hatom|hAtom]] etc.) need a mechanism to include a portion of data from area of a page into another area of a page. This page documents this pattern for re-use in those microformats and any others that need this feature.

; Author: Tantek Çelik

__TOC__

== Background ==

In [[hresume|hResume]], we needed the ability to include the name from the hCard at the top of the resume for a person into their hCards in the middle of the resume which represented each of their job hCards (job title, organization name, address etc.), and thus developed the [http://microformats.org/wiki/resume-brainstorming#hCard_reference_via_object hCard reference via object technique].

== class name "include" ==

In order to make this more explicit (helps forward compatibility for parsers), we are adding the class name "include" on the object element to indicate that that object refers to a subtree which should be included in its place by microformat parsers.

'''Proposal 1:''' Allow the use of <nowiki><a href class="include"></nowiki> as a secondary include-pattern mechanism, due to some browsers mishandling the object include-pattern. See [[include-pattern-feedback]] for details.

== object include example ==

Here is an example of an [[hcard|hCard]] you could have at the top of a page, shown here also as a verbose hCard for purposes of illustration that the reference may be to a subtree, not just a text node:

<pre><nowiki>


James Levine


</nowiki></pre>

Somewhere else on the page, you could have another hCard which would re-use that "fn n" content from the first hCard:

<pre><nowiki>

<object data="#j" class="include"></object>
SimplyHired
Microformat Brainstormer

</nowiki></pre>

Thus a microformat parser would treat the above as follows, with the object include completely replaced by the subtree that it references:

<pre><nowiki>


James Levine

SimplyHired
Microformat Brainstormer

</nowiki></pre>

This method of hCard property indirection via an object element can apply to any/all properties in class-based microformats.

Note 1: '''the object data attribute MUST be a local ID reference.''' External references (which would require a consuming application to load an external resource) are currently not supported by this method.

Note 2: To avoid unsightly messes in Safari, you should include the following style rule in a style sheet for the page:
<pre><nowiki>
object.include { width:0; height:0 }
</nowiki></pre>

Note 3: To prevent infinite loops, if a class="include" refers to itself or an ancestor in the parse tree, then it is ignored and has no effect on the parser.

== hyperlink include example ==

Per the proposal 1 above, here is how you would code the above object include example using the <nowiki><a href></nowiki> tag.

<pre><nowiki>

<a href="#j" class="include"></a>
SimplyHired
Microformat Brainstormer

</nowiki></pre>

Changes:
# a open/close tag instead of object open/close tag
# href attribute instead of data attribute
# ... that's it. only 2 changes.

And just as in the object include example, the end effective result to the parser is the same, and the same '''Notes''' apply.

<pre><nowiki>


James Levine

SimplyHired
Microformat Brainstormer

</nowiki></pre>

== Acknowledgments ==

Thanks to discussions and brainstorms with a bunch of folks: Ryan King, James Levine, the whole crowd at the [http://mashupcamp.com/index.cgi?HAtomFinalization Microformats specifications working session] at MashupCamp, Brian Suda, Scott Reynen, Drew McLellan.

== Specifications Using ==
* [[hresume|hResume]]
* [[hreview|hReview]]

=== Considering ===
* [[hatom|hAtom]]
* [[hcalendar|hCalendar]]
* [[hcard|hCard]]
* [[currency]]

== Implementations ==
* X2V implements the [[include-pattern]] when parsing [[hcard|hCards]] and [[hcalendar|hCalendars]] for both object.include and a.include.

== References ==

=== Normative ===
* HTML 4.01
* XHTML 1.0

=== Informative ===
* [[hcard|hCard]]

=== Related ===

* [http://www.mnot.net/javascript/hinclude.html Introducing HInclude] by Mark Nottingham.
** HInclude is a markup extension + javascript library for including *external* files into an XHTML document.

== Discussions ==
* Feedback is encouraged on the [[include-pattern-feedback]] page.
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

=== Q&A ===
* If you have any questions about include-pattern, check the [[include-pattern-faq|include-pattern FAQ]], and if you don't find answers, add your questions to the end of the page!

=== Issues ===
* Please add any issues with the specification to the separate [[include-pattern-issues|include-pattern issues]] document.

measure-examples

2006-10-06T19:02:10Z

Guillaume Lebleu: /* [http://www.royalpalmshotel.com/ Royal Palms Hotel] */

= Measure Examples =

This page collects examples of measures on the Web.

== [http://www.ebay.com eBay] ==

Search for "feet", "mpg", "mph", "sec" on eBay, you will find examples similar to the following ones:

<pre>
<h1 class="itemTitle">S-Video TV Out 1.5m 5 Feet Extension S Video DVD Cable</h1>
</pre>

<pre>
<li>Measures 60" (1.5m) long</li>
<li>Extend your S-video cable by 1.5m long</li>
</pre>

<pre>
<DIV> Power: 
<LI>620 hp @ 5,200 rpm
<LI>650 lb-ft @ 4,000 rpm Performance:
<LI>0 - 60 mph: 3.7 sec. * </LI></DIV>
<DIV>
<LI>1/4 mile: 12.1 sec. @ 114 mph</LI></DIV>
<DIV>
</pre>

== [http://www.royalpalmshotel.com/ Royal Palms Hotel] ==

* Use of "hightemp" as classname
* Link to a page with detailed weather

<pre>
<div id="nav-weather-footer">
Local Time: 11:52 am Local Temp: <a href="weather.php">88F/31C</a> </div>
</pre>

On the [http://www.royalpalmshotel.com/weather.php web page] with detailed weather.

* Use of "temp" as classname
* Use of "high" for high temperature (this would be more relevant for a weather forecas microformats)
* Use of "low" for low temperature (this would be more relevant for a weather forecas microformats)

<pre>
<td class="temp">
 
Rain Showers Likely
<div class="high">Hi: 88°F</div>
<div class="low">Lo: 67°F</div>
</td>
</pre>

measure-examples

2006-10-06T18:56:48Z

Guillaume Lebleu: /* [http://www.royalpalmshotel.com/ Royal Palms Hotel] */

measure-examples

2006-10-06T18:56:16Z

Guillaume Lebleu:

currency-examples

2006-10-03T18:29:23Z

Guillaume Lebleu: /* [http://tonto.eia.doe.gov/oog/info/ngw/historical/2004/06_24/ngupdate.asp Energy Information Administration] */

= Currency Examples =
The following are real-world examples and brainstorming for marking up '''[[currency]]'''..

== The Problem ==

The problem: how to explicitly specify a) that a figure/number relates to money; and b) the currency of a stated figure.

<ul>
<li>The currency sign cannot be used reliably since the same sign (or symbol) may represent more than one currency. eg. $ is used for many different dollars (USD, AUD, CAD...) and even [http://en.wikipedia.org/wiki/Currency_sign#Examples other units like pesos].</li>
<li>The language of the page is not sufficient to define the currency of prices in the page:
<ul>
<li>More than one currency may be used by people who speak the same language.</li>
<li>The page may be written in one language and still quote prices/figures in a different country's currency.</li>
<li>Even if a country can be identified, more than one currency may be used in that country.</li>
</ul>
</li>
</ul>

Converting currency figures is a reasonably easy problem to solve as indicated by the [[#Existing_Practices]]. However many automated conversion tools must make assumptions about the original figure's currency - eg. assuming a USD for all uses of $, or British Pounds for £ (which is also [http://en.wikipedia.org/wiki/Lira sometimes used to denote Lira]).

===Related problems===
"Amounts" in arbitrary units is a bit harder and necessary for several applications.

For example, consider the work that has been done on a recipe microformat.

[[recipe-examples]]

Though we haven't reached this problem yet in the research, I can see it
coming:

Say you wanted to create a "shopping list" application which you could tell which recipes you wanted to cook, and have it automatically total up all the various amounts of ingredients and give you the net amount of stuff you wanted to pick up.

It would need to be able to determine precise amounts/units of each ingredient. This might turn out to be like the currency problem, or it might be more complex, given the variety of units used in recipes, English vs. metric etc. That's a case that might need a microformat. We need more research and analysis to really justify it, but I can see it within the realm of probable possibility.

===Use of currency amounts in tables===

Representing currency amounts in a table format is very common. For instance, see [http://investor.google.com/fin_data.html Google Financials].

In this table representation, it does not make sense to provide the currency information for each cell. Instead, it should be provided once at the table, thead, tr, or th, level, and then a td may override the default value. This is very similar to the common practice of indicating the currency and formatting in plain english: "Numbers in thousands of dollars" in the table title/subtitle or legend.

The microformat for currency amounts should provide a way to represent a default currency for all children of a table, thead, tr, or th nodes.
The currency symbol/abbreviation should be optional in for elements defined as containing currency values/amounts, if a default currency has been defined in one of the ancestor elements.

==Contributors==
* [http://weblog.200ok.com.au/ Ben Buchanan] (proponent)
* Arve Bersvendsen
* [http://tantek.com/log/ Tantek Çelik]
* [http://steve.ganz.name/ Steve Ganz]
* Charles Iliya Krempeaux
*[[User:AndyMabbett|Andy Mabbett]] (2nd proponent)
* Ciaran McNulty
* Mike Stickel
* Ben Ward
* Guillaume Lebleu

== Real-World Examples ==
''Links to public web pages, either popular or insightful''

=== [http://enterpriseforum.mit.edu/mindshare/startingup/dilution.html MIT Enterprise Forum ] ===

<pre>$1 million in equity</pre>

<pre>$2.50 a share</pre>

See also [[measure]]

=== [http://tonto.eia.doe.gov/oog/info/ngw/historical/2004/06_24/ngupdate.asp Energy Information Administration] ===

<pre>23 cents per barrel</pre>

Also in this [http://www.eia.doe.gov/emeu/international/oilprice.html page]:

<pre>(U.S. Cents per Gallon)</pre>

<pre>(Euros per Thousand Liters)</pre>

<pre>(U.S. Dollars per Gallon)</pre>

See also [[measure]]

=== [http://www.cbc.ca/money/story/2005/08/08/oil-050808.html CBCNews] ===

<pre>$63.94 US per barrel, up $1.63 US</pre>

=== [http://finance.google.com/finance?q=google&hl=en Google Finance] ===

The current price of a stock:

<pre>401.90</pre>

=== [http://www.ebay.com eBay] ===

eBay marks prices as "ebcPr". eBay c? Price.

<pre>
<td class="ebcPr">$11.70 $12.95 </td>
</pre>

=== [http://code.google.com/webstats/2005-12/classes.html Google] ===

The Google Web Authoring Statistics mentions that "price" is the 40th most used class name.

Something like:

<pre>
$39.99
</pre>

=== [http://us.mcafee.com/root/package.asp?pkgid=100 McAfee] ===
<pre>
$39.99 (USD)
</pre>

=== [http://www.amazon.com/gp/product/0764597582/sr=8-9/qid=1153301402/ref=sr_1_9/002-9103678-0608852?ie=UTF8 Amazon] ===

<pre><td class="price">$34.85</td></pre>

=== [https://secure.vmp.com/signup/adv_signup.php?locale=fr_CA Bell Canada in French Canadian] ===

<pre>Niveau de service Premium - 125 $*</pre>

Note the placement of the dollar sign AFTER the number.

=== [https://secure.vmp.com/signup/adv_signup.php?locale=en_US Bell Canada in US English] ===

<pre>Premium Service Level - $125*</pre>

===Historic prices===
*[http://www.westmidlandbirdclub.com/biblio/worcs.htm#MalvernHand West Midland Bird Club Bibliography] (Published prices of old books)
*[http://www.westmidlandbirdclub.com/reviews/rarer.htm West Midland Bird Club CD-ROM review] (price at time of review; since reduced)
*[http://en.wikipedia.org/wiki/Bleak_House#Original_publication Wikipedia: Bleak House]
**"Like most Dickens novels, Bleak House was published in 19 monthly instalments, each containing 32 pages of text and two illustrations by Phiz. Each cost one shilling, except for the last, which was a double issue and cost two." Dates in the subsequent table range monthly from March 1852 - September 1853
*[http://en.wikipedia.org/wiki/1922_in_Germany#Inflation_and_Repercussions Wikpedia: 1922 in Germany]
**"Despite the ending of cash payments for the rest of 1922, the main cause of Germany's inability to pay, the steady depreciation of the mark, was ongoing. Towards the end of the year it assumed a disastrous rapidity. On August 1, the US Dollar still stood at 643 Marks to the Dollar and the British Pound at 2,850 Marks to the Pound. But on September 5 the dollar had already risen to 1,440 Marks and the pound to 6,525 Marks, and in December the pound was worth between 30,000 and 40,000 marks and the dollar between 7,000 and 9,000."
*[http://news.bbc.co.uk/1/hi/business/1096916.stm BBC News story dated 2 January, 2001]
**"A barrel of Brent crude for February delivery came within range of $25 a barrel on Tuesday before slipping to $24.35, a closing price 48 cents above Friday's closing price of $23.87. In New York, the price of Nymex (New York Merchantile Exchange) crude reached $27.40 a barrel before settling at $27.40, a gain of 41 cents or 1.5% on the day. Nymex oil prices in 2000 averaged $30.20 a barrel, the highest level since 1983, and well above the 1999 average of $19.25. Traders also saw support for the oil price from the Opec basket of seven crude oils which stood at $21.75 a barrell on 29 December 2000. That was the seventh day the price stayed below a preferred range of $22-$28 a barrell. Under an Opec price stability measure, output will be cut by 500,000 barrels a day if the basket price stay below $22 for more than 10 days."
*[http://news.bbc.co.uk/1/hi/uk/911569.stm BBC News story dated 5 September, 2000]
**"The Millennium Commission's decision to grant an extra £47m to the Dome has been widely condemned by MPs on various political hues."
*[http://www.jamaica-gleaner.com/pages/history/story0014.html Jamaica and the Great War]
**"in 1917 [...] unemployment was high and wages were low - men received 9 pence a day to cut cane."
*[http://www.wilkiecollins.demon.co.uk/coinage/coins.htm Money and Coinage in Victorian Britain]
*[http://www.margaretmorgan.com/wesley/state.html Macaulay on the State of England in 1685]
**"In 1661 the justices at Chelmsford had fixed the wages of the Essex labourer, who was not boarded, at six shillings in winter and seven in summer."
*[http://www.bbc.co.uk/ww2peopleswar/stories/74/a4095074.shtml BBC - WW2 People's War]
**"I left [school] at Easter 1938. As soon as I had left school, my Father insisted that I went to work for my Uncle. My wages were 5 shillings per week plus board & lodgings"
*[http://privatewww.essex.ac.uk/~alan/family/N-Money.html Relative Value of Sums of Money]

== Existing Practices ==

===Firefox Extension===
[http://viewmycurrency.wordpress.com/about/ Firefox Currency Converter - ViewMyCurrency]

Note: the [http://viewmycurrency.backpackit.com/pub/403081 current bug list] illustrates some problems of identifying currencies based on page content alone:
<blockquote>
<ul>
<li>All $ symbols are treated as USD Very annoying if you are Australian, Canadian etc. (Needs a new feature)</li>
<li>‘Euro 2006 Championship’ should not be converted.</li>
<li>...</li>
<li>Don’t convert CVS keywords . $Revision: 1.3 $ should not be treated as dollars.</li>
</ul>
</blockquote>

===Greasemonkey Scripts ===
[http://nybblelabs.org.uk/projects/exchequer Exchequer]

[http://6v8.gamboni.org/Greasemonkey-Yahoo-Finance.html Yahoo! Finance Currency Converter]

===Relevant Standards ===
[http://www.xe.com/iso4217.htm ISO 4217 Codes]

== See Also ==
* [[currency-brainstorming]]
**[[currency-brainstorming#Straw man proposal]]
* [[abbr-design-pattern]]