value-class-pattern-ja: Difference between revisions
(→実装: sync: english: 2009-08-26T15:17:08) |
(sync: english: 2009-10-01T01:28:08) |
||
Line 1: | Line 1: | ||
<entry-title>Value Class Pattern</entry-title> | <entry-title>Value Class Pattern</entry-title> | ||
<!-- sync: english: 2009- | <!-- sync: english: 2009-10-01T01:28:08 --> | ||
value class パターンは hCard の「[[hcard-ja#値の抜粋|値の抜粋]]」から派生しています。 | value class パターンは hCard の「[[hcard-ja#値の抜粋|値の抜粋]]」から派生しています。 | ||
Line 91: | Line 91: | ||
== 日時の値 == | == 日時の値 == | ||
=== 概要 === | |||
マイクロフォーマットのプロパティには ISO8601 の日時の値を要求するものがあります。例えば [[hcalendar-ja|hCalendar]] の <code>dtstart</code> と <code>dtend</code> や [[hAtom]] の <code>published</code> です。 | マイクロフォーマットのプロパティには ISO8601 の日時の値を要求するものがあります。例えば [[hcalendar-ja|hCalendar]] の <code>dtstart</code> と <code>dtend</code> や [[hAtom]] の <code>published</code> です。 | ||
value class パターンを使って、日付と時刻を別々に記述し、それを一つの日時の値に結合することができます。 | value class パターンを使って、日付と時刻を別々に記述し、それを一つの日時の値に結合することができます。 | ||
これは hCalendar の 'dtstart' プロパティに 'value' 要素を使った例です: | |||
<source lang=html4strict> | <source lang=html4strict> | ||
Line 107: | Line 108: | ||
</source> | </source> | ||
次の 'dtstart' の値を生成します: | |||
<source lang=text> | <source lang=text> | ||
DTSTART:2008-06-24T18:30:00 | DTSTART:2008-06-24T18:30:00 | ||
</source> | |||
また、iCalendar 変換プログラムは次の DTSTART を生成します: | |||
<source lang=text> | |||
DTSTART:20080624T183000 | |||
</source> | </source> | ||
Line 143: | Line 150: | ||
** HH は時刻のうちの「時」で、00 から 24 まで、10 未満の時の 最初の 0 は省略できます。 | ** HH は時刻のうちの「時」で、00 から 24 まで、10 未満の時の 最初の 0 は省略できます。 | ||
** MM は 00 から 59 までの分です。 | ** MM は 00 から 59 までの分です。 | ||
** SS は 00 から 59(うるう秒では 60)までの秒で、任意です。省略した場合には 00 | ** SS は 00 から 59(うるう秒では 60)までの秒で、任意です。省略した場合には 00 秒と推測します。 | ||
** XX はタイムゾーンの時間オフセットで、00 から 12 まで、10 未満の時の 最初の 0 は省略できます。 | ** XX はタイムゾーンの時間オフセットで、00 から 12 まで、10 未満の時の 最初の 0 は省略できます。 | ||
** YY はタイムゾーンの分オフセットで 00 から 59 ですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。 | ** YY はタイムゾーンの分オフセットで 00 から 59 ですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。 | ||
Line 149: | Line 156: | ||
** class value パターンを使うためは、時、分、秒をコロン ":" で区切る必要があります。 | ** class value パターンを使うためは、時、分、秒をコロン ":" で区切る必要があります。 | ||
** ですが、タイムゾーンオフセットでの時間と分を区切るコロン ":" は''任意''で、タイムゾーンオフセットと時刻の混同を減らすため、推奨されません。 | ** ですが、タイムゾーンオフセットでの時間と分を区切るコロン ":" は''任意''で、タイムゾーンオフセットと時刻の混同を減らすため、推奨されません。 | ||
** | ** HH の 12 という値を 00 として扱うサフィックス { }"am"|{ }"a.m." や HH の 12 未満の値に 12 を加えるサフィックス { }"pm"|{ }"p.m." は―― [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia 英語版の 12 時間時計]に従って――大文字と小文字を区別しません。メモ:[[X2V]] はこれを実装しています。 | ||
*** HH:MM:SSam | |||
*** HH:MM:SSpm | |||
*** HH:MMam | |||
*** HH:MMpm | |||
*** HHam | |||
*** HHpm | |||
*** "am" や "pm" とある場合、"am または a.m." や "pm または p.m." を意味します。 | |||
*** MM を省略した場合には 00 分と推測します。 | |||
** 時刻を定義する "value" 要素が他にあっても無視します。 | ** 時刻を定義する "value" 要素が他にあっても無視します。 | ||
* 値に、仕様に従ったタイムゾーン * のみ * がある場合、それは次のいずれかにマッチするかパースします。 | * 値に、仕様に従ったタイムゾーン * のみ * がある場合、それは次のいずれかにマッチするかパースします。 | ||
Line 163: | Line 178: | ||
** Z is the literal 'Z' to indicate GMT. | ** Z is the literal 'Z' to indicate GMT. | ||
** タイムゾーンを定義する "value" 要素が他にあっても無視します。 | ** タイムゾーンを定義する "value" 要素が他にあっても無視します。 | ||
If by parsing the "value" element(s), at least a specific date has been found, then the "value" is overall valid, and the parser assembles the overall datetime value by concatenating the specific date, "T" and specific time (if time was specified, with 00 seconds implied if no seconds are provided), and specific timezone (if timezone and a specific time was specified). | |||
* YYYY-MM-DD - no time specified | |||
* YYYY-MM-DDTHH:MM:SS - time specified but no timezone. This is a floating time. | |||
* YYYY-MM-DDTHH:MM:SS-XXYY or | |||
* YYYY-MM-DDTHH:MM:SSZ or | |||
* YYYY-MM-DDTHH:MM:SS+XXYY - both time and timezone were specified. | |||
=== フォーマットに特化した詳細 === | |||
The following are format specific details and <span id="format_specific_optimizations">optimizations</span> that make use of the value-class-pattern. | |||
;<span style="font-size:smaller">short URL for this section</span> | |||
:http://tr.im/vcpfso | |||
==== hCalendar の dtend での日付の推測処理 ==== | |||
Typically events that start and end the same day only display the date of the event once (makes sense per the DRY [[principle]]) (real world examples: [http://upcoming.yahoo.com/event/3010807/ Upcoming], ... more examples with URLs would help for thoroughness). | |||
Thus it would be convenient if we could imply an [[hCalendar]] event "dtend" date from its "dtstart" date when only the time (and optionally timezone) was specified for its "dtend", e.g.: | |||
<source lang=html4strict> | |||
<span class="vevent"> | |||
The <span class="summary">party</span> will be on | |||
<span class="dtstart"> | |||
<span class="value">2009-06-26</span>, from | |||
<span class="value">19:00</span></span> to | |||
<span class="dtend"><span class="value">22:00</span></span>. | |||
</span> | |||
</source> | |||
To simplify this further for authors, hCalendar processors could treat the specifying of just the time per the value-class-pattern date and time value rules, and thus eliminate the need for the "value" span inside the "dtend" span: | |||
<source lang=html4strict> | |||
<span class="vevent"> | |||
The <span class="summary">party</span> will be on | |||
<span class="dtstart"> | |||
<span class="value">2009-06-26</span>, from | |||
<span class="value">19:00</span></span> to | |||
<span class="dtend">22:00</span>. | |||
</span> | |||
</source> | |||
hCalendar to iCalendar converters should produce the following iCalendar fragment (as part of a valid .ics file) from either of the above two examples: | |||
<source lang=text> | |||
BEGIN:VEVENT | |||
SUMMARY:party | |||
DTSTART:20090626T190000 | |||
DTEND:20090626T220000 | |||
END:VEVENT | |||
</source> | |||
Note: [[X2V]] has implemented dtend implied date from dtstart. | |||
Examples "in the wild": | |||
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop (real world example, but on this wiki). | |||
==== iCalendar 生成プログラム ==== | |||
microformats implementations which consume [[hCalendar]] and generate iCalendar {{must}} in addition: | |||
* remove any dash "-" separators in the date. | |||
* remove any colon ":" separators in the time. | |||
* add a whole day to any date-only (lacking a specified time) (date inclusive) hCalendar <code>dtend</code> property values in order to generate an (date exclusive) iCalendar <code>DTEND</code> property value with the same meaning, per the resolution to the [[dtend-issue]]. | |||
* perform datetime math on any +/- relative timezone value, and produce an effective UTC value ending with "Z". | |||
==== hAtom の updated での日付の推測処理 ==== | |||
Similarly, in blog posts that indicate both when they were "published" and "updated", the date is usually only displayed once, typically when "published" (real world examples with URLs would help for thoroughness). | |||
Thus it would be convenient if we could imply an [[hAtom]] entry "updated" date from its "published" date when only the time (and optionally timezone) was specified for its "updated", e.g. for a blog post that was updated the same day: | |||
<source lang=html4strict> | |||
<span class="hentry"> | |||
<span class="entry-summary">short blog post example</span> | |||
was published on <span class="published"> | |||
<span class="value">2009-08-01</span> at <span class="value">12:06</span></span> | |||
and updated at <span class="updated"><span class="value">12:10</span></span>. | |||
</span> | |||
</source> | |||
To simplify this further for authors, hAtom processors could treat the specifying of just the time per the value-class-pattern date and time value rules, and thus eliminate the need for the "value" span inside the "updated" span: | |||
<source lang=html4strict> | |||
<span class="hentry"> | |||
<span class="entry-summary">short blog post example</span> | |||
was published on <span class="published"> | |||
<span class="value">2009-08-01</span> at <span class="value">12:06</span></span> | |||
and updated at <span class="updated">12:10</span>. | |||
</span> | |||
</source> | |||
==== Atom 生成プログラム ==== | |||
microformats implementations which consume [[hAtom]] and generate | |||
Atom {{must}} in addition: | |||
* normalize all date and datetime values to [[RFC3339]]. | |||
=== 起源とテスト === | === 起源とテスト === | ||
この節は<em>参考用</em>です。 | |||
value class パターンでの日付と時刻の扱い方は、元々は [[value-excerption-pattern-brainstorming#date_and_time_separation|value-excerption-pattern-brainstorming ページでブレインストーミングしており]]、その分析とフィードバックを起源としています。そこでは拡張にあたっての別の考え方と共に歴史的な詳細を見られるのが興味深いでしょう。 | value class パターンでの日付と時刻の扱い方は、元々は [[value-excerption-pattern-brainstorming#date_and_time_separation|value-excerption-pattern-brainstorming ページでブレインストーミングしており]]、その分析とフィードバックを起源としています。そこでは拡張にあたっての別の考え方と共に歴史的な詳細を見られるのが興味深いでしょう。 | ||
テストケースは [[value-class-date-time-tests]] をご覧ください。 | |||
== <code>title</code> 属性からの値のパース == | == <code>title</code> 属性からの値のパース == | ||
Line 265: | Line 374: | ||
In future use, ''specification authors'' may inherit use of <code>value-title</code> by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and <abbr>DRY</abbr>. | In future use, ''specification authors'' may inherit use of <code>value-title</code> by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and <abbr>DRY</abbr>. | ||
=== <abbr title='Frequently Asked Questions'>FAQ</abbr> | == テストケース == | ||
See [[value-class-pattern-tests]]. | |||
== <abbr title='Frequently Asked Questions'>FAQ</abbr> == | |||
This section is '''informative'''. | This section is '''informative'''. | ||
Line 274: | Line 386: | ||
** The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states <code>class</code> is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data. | ** The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states <code>class</code> is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data. | ||
* '''Why use an 'empty' element? Why not make up a new attribute, like ‘data’?''' | * '''Why use an 'empty' element? Why not make up a new attribute, like ‘data’?''' | ||
** Microformats exist and function in valid HTML4 and XHTML1. Those are the current standards for web development, and microformats exist for use ''now''. In the future, perhaps | ** Microformats exist and function in ''valid'' HTML4 and XHTML1. Those are the current standards for web development, and microformats exist for use ''now''. In the future, perhaps revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistent document structure (where machine-form and human-form data are siblings). | ||
* '''The <code>title</code> attribute should only be used for content!''' | * '''The <code>title</code> attribute should only be used for content!''' | ||
** The <code>title</code> attribute | ** The <code>title</code> attribute "is" used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers. | ||
</div> | </div> | ||
Line 290: | Line 402: | ||
--> | --> | ||
* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] This pages uses a whole range of different patterns for both hCard and hCalendar, using both value and value-title, mostly derived from the specification above | |||
* [http://georgebrock.com/ George Brocklehurst's activity stream] and [http://blog.georgebrock.com/ blog] use "value-title" for hAtom <code>published</code> property | * [http://georgebrock.com/ George Brocklehurst's activity stream] and [http://blog.georgebrock.com/ blog] use "value-title" for hAtom <code>published</code> property | ||
* [http://ben-ward.co.uk/ Ben Ward's home page] uses: | * [http://ben-ward.co.uk/ Ben Ward's home page] uses: | ||
Line 318: | Line 431: | ||
* [[Optimus]] v0.8 and later implements <code>value-title</code> as [http://twitter.com/DmitryBaranovsk/status/1891253248 announced by Dmitry Baranovskiy]. | * [[Optimus]] v0.8 and later implements <code>value-title</code> as [http://twitter.com/DmitryBaranovsk/status/1891253248 announced by Dmitry Baranovskiy]. | ||
* ... add your implementation(s) that parse or generate the value-class-pattern here, along with which features you support (hopefully all!) and note any limitations if any. | * ... add your implementation(s) that parse or generate the value-class-pattern here, along with which features you support (hopefully all!) and note any limitations if any. | ||
== 記事 == | |||
Articles and <span id="Blog_Posts">blog posts</span> discussing the value class pattern, most recent first. | |||
When this section gets too big, create a separate page like: [[value-class-pattern-articles]] | |||
* <span class="hentry"><span class="published">2009-08-25</span> <span class="entry-summary">MIX Online: <span class="entry-title">[http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern]</span></span> by <span class="author vcard"><span class="fn">Jeremy Keith</span></span></span> | |||
* [http://ablognotlimited.com/s/106 Getting Semantic With Microformats, Part 8: Value Class Pattern] -- A very thorough writeup by Emily Lewis on the value class pattern | |||
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation] | |||
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern] | |||
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern] | |||
== 関連ページ == | == 関連ページ == | ||
This section is '''informative'''. | This section is '''informative'''. | ||
* [[value-class-pattern-tests]] | |||
* [[value-excerption-pattern-issues]] | * [[value-excerption-pattern-issues]] | ||
* [[hcard#Value_excerpting|hCard: Value Excepting]] | * [[hcard#Value_excerpting|hCard: Value Excepting]] | ||
* [[value-excerption-pattern-brainstorming]] | * [[value-excerption-pattern-brainstorming]] | ||
* [[machine-data|Machine Data in Microformats]] | * [[machine-data|Machine Data in Microformats]] |
Revision as of 18:27, 17 October 2009
<entry-title>Value Class Pattern</entry-title>
value class パターンは hCard の「値の抜粋」から派生しています。
この機能は完成し、マークアップに使う準備が整っていると考えています。実装者は適宜アップデートしてフィードバックすることが推奨されます。注:実装者からのフィードバックによってパースの厳密な動きは変わるかもしれませんが、主な手順は安定しています。このページの更新をチェックしておいてください。
ブログのアナウンスも参照してください。
- 編集者
- Ben Ward
- Tantek Celik
- 短縮 URL
- http://tr.im/valueclass
マイクロフォーマットのプロパティの値として、ある要素の一部だけが使われることがあります。これは hCard の tel: type
や tel: value
など、任意サブプロパティがある時に起こる可能性があります。また、プロパティの一番適切な構造として他の内容を含むということもあります。
こういったプロパティでは、value
という特別な class 名を使って大きな要素内容からの関連データの抜粋をマークアップします。
簡単な例
自宅の電話番号をマークアップするとしましょう。
vCard の一部はこうです。
TEL;TYPE=HOME:+1.415.555.1212
hCard の一部はこうです。
<span class="tel">
<span class="type">Home</span>:
<span class="value">+1.415.555.1212</span>
</span>
この場合、tel
の value
は +1.415.555.1212
であり、Home: +1.415.555.1212
とはなりません。
マイクロフォーマットのプロパティの値は、そのプロパティを表現している要素中で複数の断片に分けなければならないこともあります。簡潔な文字列や tel のような値を要求するマイクロフォーマットプロパティのため、"value" という class 名の要素(value 要素)を複数使ってそういった断片を抜き出し、単一の値につなぎ合わせることができます。
別の例を挙げます。今度は(イギリスに)地域化した電話番号を使っています。
<span class="tel">
<span class="type">Home</span>:
<span class="value">+44</span> (0) <span class="value">1223 123 123</span>
</span>
この場合、+441223123123 というのが電話番号の妥当なデータですが、イギリスで国内向けの電話番号を表すには (0) を含めます。つまり、世界のどこかから +441223123123 で電話でき、イギリス国内からは 01223123123 で電話できるのです。+4401223123123 というのは無効な番号なので、地域化された一般的な表示はデータを邪魔することになります。
上のマークアップでは二つの value
クラスが電話番号の文字列の対象となり、慣例的な表現に従いながら国際化された有効な番号にもなっています。
もう一つ例を示します。geo の座標に場所の名前を追加しています。
<p>ブリックレイヤーズ・アームズの外をぶらぶらしています。
<span class="geo">
51° 30' 48.45", -0° 8' 53.23"
(<span class="value">51.513458;-0.14812</span>)
</span>
</p>
文字列全体が地理上の場所ですが、数字だけがマイクロフォーマットパーサーが扱うべき座標をエンコードしているので、value
class を使うことでそれを度分秒の形式から分離しています。表現にはそれを含めて、完全な情報としています。
パースの基本
- value class パターンは簡潔な文字列、一覧になっている値、電話番号、日時プロパティのみに適用されます。email、URL、URI、UID といった種類のプロパティのパースには影響しません。
- そういったマイクロフォーマットプロパティの class 名を持つ要素に
value
という子孫要素("value" 要素)がある場合は、パーサーは、その要素の以下の部分を使うべきです。- value 要素が
img
かarea
要素であれば、その要素のalt
属性の値を使います。 - value 要素が
abbr
要素であれば、その要素のtitle
属性の値を使います。 - その他の要素の場合は、内部のテキストを使います。
- value 要素が
value
という class 名を持つプロパティに複数の子孫がある場合(複数の value 要素)- そのマイクロフォーマットプロパティが簡潔な文字列、一覧になっている値、電話番号を要求していれば、value 要素から抽出した値は、追加の文字や空白を挿入せずに結合するべきです。
- マイクロフォーマットプロパティが日時の値を要求している場合については日時のパースの節を参照してください。
value
という class を持つ子孫は、一階層を越えて深くパースしてはいけません。つまり、value
という class のfoo
要素にvalue
class のbar
という子孫があった場合、value
としてfoo
の内容を使います。プロパティの値をさらに分離するために class がvalue
の追加要素を入れ子にして使うことはできません。
例
<p class="description">
<span class="value">
<em class="value">子犬は最高!</em>
<strong>でも子猫はもっといい!</strong>
</span>
</p>
この例では、description
に子要素‘value
’があり、その子要素には孫要素の‘value
’があります。ですが、value
のパースは最初の階層で止まり、description
のデータは「<em class="value">子犬は最高!</em><strong>でも子猫はもっといい!</strong>
」であり、「子犬は最高!」ではありません。
日時の値
概要
マイクロフォーマットのプロパティには ISO8601 の日時の値を要求するものがあります。例えば hCalendar の dtstart
と dtend
や hAtom の published
です。
value class パターンを使って、日付と時刻を別々に記述し、それを一つの日時の値に結合することができます。
これは hCalendar の 'dtstart' プロパティに 'value' 要素を使った例です:
<p>毎週のディナーは、
<span class="dtstart">
<abbr class="value" title="2008-06-24">今週は火曜日</abbr>
の <span class="value">18:30</span>
</span>
に。
</p>
次の 'dtstart' の値を生成します:
DTSTART:2008-06-24T18:30:00
また、iCalendar 変換プログラムは次の DTSTART を生成します:
DTSTART:20080624T183000
タイムゾーンが無いことは、特定のタイムゾーンに依存しない日時である「変動」日時("floating" datetime)であることを示します。変動日時の例としては、午前7時になるようセットした目覚まし時計や一般的な労働時間の午前9時~午後5時があります。
日付と時刻のパース
全ての(それぞれのマイクロフォーマット仕様で定義された)日付と時刻のプロパティに関して、上述した value class パターンのパースルールに加えて(場合によっては代わりとして)以下のルールが適用されます。
"value" 要素が見付かった時、その要素から次のようにして値をパースします。
- 要素が
img
かarea
要素であれば、その要素のalt
属性の値を使います。 - 要素が
abbr
要素であれば、その要素のtitle
属性の値を使います。 - その他の要素の場合は、内部のテキストを使います。
- 値に ISO8601 仕様に従った日付と時刻があるならそれを使い、"value" 要素を探すのをやめます。
- 値に、仕様に従った日付 * のみ * がある場合、特に次の ISO8601 の日付パターンに(ウィキペディアの ISO8601 概要 にあるように)適合する場合には、
- YYYY-MM-DD
- YYYY-DDD
- それを日付の値として使います。value class パターンを使うためには、ハイフン "-" で区切った年、月、日又は年間通算日(ordinal day)が必要です。
- 日付を定義する "value" 要素が他にあっても無視します。
- 値に(タイムゾーンはあっても無くても)仕様に従った時刻 * のみ * がある場合、それは時刻として次のいずれかにマッチするかパースします。
- HH:MM:SS-XX:YY
- HH:MM:SS+XX:YY
- HH:MM:SS-XXYY
- HH:MM:SS+XXYY
- HH:MM:SSZ
- HH:MM:SS
- HH:MM-XX:YY
- HH:MM+XX:YY
- HH:MM-XXYY
- HH:MM+XXYY
- HH:MMZ
- HH:MM
- HH は時刻のうちの「時」で、00 から 24 まで、10 未満の時の 最初の 0 は省略できます。
- MM は 00 から 59 までの分です。
- SS は 00 から 59(うるう秒では 60)までの秒で、任意です。省略した場合には 00 秒と推測します。
- XX はタイムゾーンの時間オフセットで、00 から 12 まで、10 未満の時の 最初の 0 は省略できます。
- YY はタイムゾーンの分オフセットで 00 から 59 ですが、実際には世界中で 00、15、30、45 分のオフセットのみが使われます。
- Z は GMT を表す文字 'Z' です。
- class value パターンを使うためは、時、分、秒をコロン ":" で区切る必要があります。
- ですが、タイムゾーンオフセットでの時間と分を区切るコロン ":" は任意で、タイムゾーンオフセットと時刻の混同を減らすため、推奨されません。
- HH の 12 という値を 00 として扱うサフィックス { }"am"|{ }"a.m." や HH の 12 未満の値に 12 を加えるサフィックス { }"pm"|{ }"p.m." は―― Wikipedia 英語版の 12 時間時計に従って――大文字と小文字を区別しません。メモ:X2V はこれを実装しています。
- HH:MM:SSam
- HH:MM:SSpm
- HH:MMam
- HH:MMpm
- HHam
- HHpm
- "am" や "pm" とある場合、"am または a.m." や "pm または p.m." を意味します。
- MM を省略した場合には 00 分と推測します。
- 時刻を定義する "value" 要素が他にあっても無視します。
- 値に、仕様に従ったタイムゾーン * のみ * がある場合、それは次のいずれかにマッチするかパースします。
- -XX:YY
- +XX:YY
- -XXYY
- +XXYY
- -XX
- +XX
- Z
- XX is the time zone hours offset, from 00 to 12 with optional leading 0 for values less than 10.
- YY is the time zone minutes offset, from 00 to 59, though in practice only 00, 15, 30, 45 minute offsets are used in global timezones.
- Z is the literal 'Z' to indicate GMT.
- タイムゾーンを定義する "value" 要素が他にあっても無視します。
If by parsing the "value" element(s), at least a specific date has been found, then the "value" is overall valid, and the parser assembles the overall datetime value by concatenating the specific date, "T" and specific time (if time was specified, with 00 seconds implied if no seconds are provided), and specific timezone (if timezone and a specific time was specified).
- YYYY-MM-DD - no time specified
- YYYY-MM-DDTHH:MM:SS - time specified but no timezone. This is a floating time.
- YYYY-MM-DDTHH:MM:SS-XXYY or
- YYYY-MM-DDTHH:MM:SSZ or
- YYYY-MM-DDTHH:MM:SS+XXYY - both time and timezone were specified.
フォーマットに特化した詳細
The following are format specific details and optimizations that make use of the value-class-pattern.
- short URL for this section
- http://tr.im/vcpfso
hCalendar の dtend での日付の推測処理
Typically events that start and end the same day only display the date of the event once (makes sense per the DRY principle) (real world examples: Upcoming, ... more examples with URLs would help for thoroughness).
Thus it would be convenient if we could imply an hCalendar event "dtend" date from its "dtstart" date when only the time (and optionally timezone) was specified for its "dtend", e.g.:
<span class="vevent">
The <span class="summary">party</span> will be on
<span class="dtstart">
<span class="value">2009-06-26</span>, from
<span class="value">19:00</span></span> to
<span class="dtend"><span class="value">22:00</span></span>.
</span>
To simplify this further for authors, hCalendar processors could treat the specifying of just the time per the value-class-pattern date and time value rules, and thus eliminate the need for the "value" span inside the "dtend" span:
<span class="vevent">
The <span class="summary">party</span> will be on
<span class="dtstart">
<span class="value">2009-06-26</span>, from
<span class="value">19:00</span></span> to
<span class="dtend">22:00</span>.
</span>
hCalendar to iCalendar converters should produce the following iCalendar fragment (as part of a valid .ics file) from either of the above two examples:
BEGIN:VEVENT
SUMMARY:party
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
Note: X2V has implemented dtend implied date from dtstart.
Examples "in the wild":
- http://microformats.org/wiki/events/2009-08-12-nyc-workshop (real world example, but on this wiki).
iCalendar 生成プログラム
microformats implementations which consume hCalendar and generate iCalendar MUST in addition:
- remove any dash "-" separators in the date.
- remove any colon ":" separators in the time.
- add a whole day to any date-only (lacking a specified time) (date inclusive) hCalendar
dtend
property values in order to generate an (date exclusive) iCalendarDTEND
property value with the same meaning, per the resolution to the dtend-issue. - perform datetime math on any +/- relative timezone value, and produce an effective UTC value ending with "Z".
hAtom の updated での日付の推測処理
Similarly, in blog posts that indicate both when they were "published" and "updated", the date is usually only displayed once, typically when "published" (real world examples with URLs would help for thoroughness).
Thus it would be convenient if we could imply an hAtom entry "updated" date from its "published" date when only the time (and optionally timezone) was specified for its "updated", e.g. for a blog post that was updated the same day:
<span class="hentry">
<span class="entry-summary">short blog post example</span>
was published on <span class="published">
<span class="value">2009-08-01</span> at <span class="value">12:06</span></span>
and updated at <span class="updated"><span class="value">12:10</span></span>.
</span>
To simplify this further for authors, hAtom processors could treat the specifying of just the time per the value-class-pattern date and time value rules, and thus eliminate the need for the "value" span inside the "updated" span:
<span class="hentry">
<span class="entry-summary">short blog post example</span>
was published on <span class="published">
<span class="value">2009-08-01</span> at <span class="value">12:06</span></span>
and updated at <span class="updated">12:10</span>.
</span>
Atom 生成プログラム
microformats implementations which consume hAtom and generate Atom MUST in addition:
- normalize all date and datetime values to RFC3339.
起源とテスト
この節は参考用です。
value class パターンでの日付と時刻の扱い方は、元々は value-excerption-pattern-brainstorming ページでブレインストーミングしており、その分析とフィードバックを起源としています。そこでは拡張にあたっての別の考え方と共に歴史的な詳細を見られるのが興味深いでしょう。
テストケースは value-class-date-time-tests をご覧ください。
title
属性からの値のパース
value-title
という class 名を使って、親プロパティのデータの値が要素の内部テキストではなく title
属性に含まれていることを示すことができます。
これを使って内容の中で同義語を使ったり、マイクロフォーマットのパース用に形式を変えた情報を、内容を壊さずこっそりと発信することができます。
例として日付の即席の地域化を使うことができます。
<p>好物のカシューナッツをいつも食べていることがこの国では高くつくことを理解したのは、
<span class='dtstart'>
<span class='value-title' title='2008'>去年</span>
</span>
のことです。
</p>
value-title
のパース規則は先述の value
と同様で、以下の点が異なります。
- マイクロフォーマットのプロパティが
value-title
という class 名の子要素を持つ場合は、要素の一部をパースするvalue
という class 名とは違い、その要素のtitle
属性の内容をパースしなければなりません。
機械向けデータ公開用の value-title
の使用
The initial usage of value-title
is used to publish alternate, parsable forms of property values in a visible context without the use of the abbr
element whose semantics already support interpretation of the 'title' attribute as an expanded, more precise form of the content.
Experience has found that there are some cases in microformats where a number of publishers want to include a precisely accurate and parsable value for a property but do not want it to be visible in their page, even as a tooltip.
For example, full ISO8601 datetimes may be confusing to readers of the page (as a tooltip or when read aloud by a screen reader), and enumerated values such as the type
subproperty of hCard's tel
property use US-English terms, which are not part of pages in any other language.
Since both of those scenarios have shown to be obstacles for a number of publishers, for these cases, and these alone, there exists a further extension of value-excerption. This extension allows the parsable form of the property to be published ‘silently’ immediately adjacent with the respective local visible content.
Here is an example, with the required use of a first child element with class name value-title
:
<p class='tel' lang='en-gb'>
<span class='type'>
<span class='value-title' title='cell'> </span>
mobile
</span>
<span class='value'>+44 7773 000 000</span>
</p>
The cell value is parsed for the 'type' subproperty, but mobile is presented to the user.
In the case of dates:
<p class='dtstart'>
<span class='value-title' title='2009-03-14T16:28-0600'> </span>
March 14th 2009, around half-past four
</p>
A microformats parser will read the ISO8601 format datetime 2009-03-14T16:28-0600, but users will only see March 14th 2009, around half-past four. Testing has shown that the ISO8601 datetime above does not get exposed to any user at all.
機械向けデータの value-title
のパース
Browsers collapse the value-title
span down to a width of 0
, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver. Screen readers do not read the contents of the title attribute of an empty span
element.
We conducted thorough testing of these parsing behaviors to ensure accessibility.
Note: Whilst the value-title
element is more gracefully written without whitespace inner-text (or as self-closing <foo />
element in XHTML), current tools such as WYSIWYG editors and HTML-Tidy will erroneously discard such elements, resulting in parsable data being thrown away by some tools. As such, <span class='value-title'> </span>
, including a single whitespace character between the opening and closing tag, is the required pattern for authors, at this time.
Parsing this final value-title
extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of DRY violations, reduce the opportunity for sites to spoof data, and encourage best practice for maintaining both forms of data accurately.
Where an element with class value-title
is to be parsed as data for a property, and that element also contains no non-whitespace content (hereafter referred to as ‘empty’), the following rules apply:
- The ‘empty’ value-title element must be the first, non-whitespace child of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
- The ‘empty’ value-title element can only be used for specific properties. Microformat specifications must explicitly state which properties may be used with this extension of the value-class-pattern.
- Where an ‘empty’ value-title element is to be used as the single property value, it must be the only such
value
content. That is, the first instance of a conformingvalue-title
element overrides all othervalue
andvalue-title
siblings and/or cousins. - Tools written to perform Conformance Testing and/or Validation of microformats should attempt to compare the machine-data and human legible forms of the property data, and advise authors if the forms do not match.
value-title の使用制限
Due to the fact that the value-title pattern hides some amount of data which tends to be a machine-specific duplicate of data that is provided in the human readable content, there are two microformats principles being compromised: visibility and DRY. Thus the applicability of this pattern is deliberately restricted to properties that have demonstrated through experience a need for it, with no known better alternative.
In general authors should:
- First, try to directly specify microformats property values inline (the most visible, no duplication),
- Then consider using the value-class pattern
- Including multiple value elements for date and time properties
- and then only if those methods are insufficient, consider the value-title pattern.
This document post-dates other microformat specifications, such that they may not yet indicate which properties permit use of this pattern. In the interim, only the following types of properties should allow the value-title pattern.
- ISO8601 date, datetime, timezone, and duration values
- Enumerated values (such as the hCard tel/email/adr 'type' subproperties)
- Co-ordinates (such as the geo 'latitude' and 'longitude' properties)
- Telephone number properties (e.g. the hCard 'tel' property)
The machine-data page has documentation of some of the properties of some specs which experience has shown need a solution like the value-title pattern.
There are some simple reference examples and tests for this pattern on value-class-pattern-tests.
In future use, specification authors may inherit use of value-title
by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visibile data and DRY.
テストケース
See value-class-pattern-tests.
FAQ
This section is informative.
Frequently asked questions about the value-class-pattern. Once this section grows too big, we'll make a separate wiki page (like value-class-faq).
- Why use an 'empty' element? Why not embed data in the class attribute?
- The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states
class
is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data.
- The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states
- Why use an 'empty' element? Why not make up a new attribute, like ‘data’?
- Microformats exist and function in valid HTML4 and XHTML1. Those are the current standards for web development, and microformats exist for use now. In the future, perhaps revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistent document structure (where machine-form and human-form data are siblings).
- The
title
attribute should only be used for content!- The
title
attribute "is" used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers.
- The
You can also refer to the general Microformats FAQ and principles.
現実の例
This section is informative.
The following sites and pages have started marking up content with the value-class-pattern, and are thus good places to go for examples with real world content to test with implementations (i.e. parsers). If you use the value-class-pattern in your content, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page (like value-class-examples-in-wild).
- Test Harness For Oomph This pages uses a whole range of different patterns for both hCard and hCalendar, using both value and value-title, mostly derived from the specification above
- George Brocklehurst's activity stream and blog use "value-title" for hAtom
published
property - Ben Ward's home page uses:
- "value-title" for hCard
bday
property - "value-title" for hAtom
updated
property
- "value-title" for hCard
- microformats.org uses:
- "value-title" for hAtom
updated
property in [microformats.org blog postss]] - date and time value separation for hCalendar
dtstart
property in microformats.org recent and upcoming events wiki page
- "value-title" for hAtom
Add your site/page(s) that use the value-class-pattern here, along with a brief description of what value-class-pattern features you use, with which microformat(s) and which of its/their properties.
実装
This section is informative.
The following implementations have been developed which either generate or parse value-class-pattern property values. If you have an value-class-pattern implementation, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page (like value-class-implementations).
- Oomph Version 2 passes Date and time values test cases and is a thorough implementation of the value class pattern.
- X2V v0.9.3 and later:
- implements Date and time values parsing, including am/pm time values
- thus passes Date and time values test cases.
- implements hCalendar implied dtend date
- implements Date and time values parsing, including am/pm time values
- Operator has *some* implementation of the value-class-pattern according to Michael Kaply, but precisely how much is implemented, for which properties (property types) and which microformats is not currently known.
- Optimus v0.8 and later implements
value-title
as announced by Dmitry Baranovskiy. - ... add your implementation(s) that parse or generate the value-class-pattern here, along with which features you support (hopefully all!) and note any limitations if any.
記事
Articles and blog posts discussing the value class pattern, most recent first. When this section gets too big, create a separate page like: value-class-pattern-articles
- 2009-08-25 MIX Online: The Value Class Pattern by
- Getting Semantic With Microformats, Part 8: Value Class Pattern -- A very thorough writeup by Emily Lewis on the value class pattern
- 2009-05-17 Adactio: Microformation
- For A Beautiful Web: Value Class Pattern
- 2009-05-12 microformats.org: Value Class Pattern
関連ページ
This section is informative.