item-brainstorming - Revision history

DavidJanes: Explicit head nod to MFO

2008-09-02T22:09:48Z

Explicit head nod to MFO

← Older revision		Revision as of 22:09, 2 September 2008
Line 151:		Line 151:

	The "hMovie" parser, because we use "item" rather than "hItem" can look inside to get selected attributes, in this case a "role" of a person. More documentation and more realistic examples would be needed to see if this differentiation is worth pursuing.		The "hMovie" parser, because we use "item" rather than "hItem" can look inside to get selected attributes, in this case a "role" of a person. More documentation and more realistic examples would be needed to see if this differentiation is worth pursuing.

			hItem is basically then [[MFO]] with additional compositing properties. (More thoughts needed here)

	= Current Summary =		= Current Summary =

DavidJanes: Added use model #4

2008-09-02T00:32:37Z

Added use model #4

← Older revision		Revision as of 00:32, 2 September 2008
Line 136:		Line 136:

	Note the precident set by hListing/hReview in compositing "item" with "vcard".		Note the precident set by hListing/hReview in compositing "item" with "vcard".

			== 4. As a composite with hitem and item ==

			Under this method, we would composite future microformats with a "hitem" top level node and "item" for scoping parts within the microformat.

			<pre><nowiki>
			<div class="hitem hmovie">
			<span class="fn">A.I.: Artificial Intelligence</span>
			<div class="item vcard">
			<span class="role">Directed</span> by...
			</div>
			</div>
			</nowiki></pre>

			The "hMovie" parser, because we use "item" rather than "hItem" can look inside to get selected attributes, in this case a "role" of a person. More documentation and more realistic examples would be needed to see if this differentiation is worth pursuing.

	= Current Summary =		= Current Summary =

DavidJanes: removed code clippings

2006-12-08T22:42:32Z

removed code clippings

← Older revision		Revision as of 22:42, 8 December 2006
Line 60:		Line 60:

	=== [[hlisting\|hListing]] ===		=== [[hlisting\|hListing]] ===

	~~<div style="background-color: #EEE">~~
	~~: item info. '''optional'''. (fn \|\| url \|\| photo \|\| [[geo]] \|\| [[adr]])~~
	~~</div>~~

	* identifier: <code>item</code>		* identifier: <code>item</code>
Line 76:		Line 72:

	=== [[hreview\|hReview]] ===		=== [[hreview\|hReview]] ===

	~~<div style="background-color: #EEE">~~
	~~: '''<code>item</code>''' info. required. '''<code>fn</code>''' ('''<code>url</code>''' \|\| '''<code>photo</code>''' )~~
	~~</div>~~

	* identifier: <code>item</code>		* identifier: <code>item</code>

DavidJanes: Explicity show attributes in use

2006-12-08T22:42:09Z

Explicity show attributes in use

← Older revision		Revision as of 22:42, 8 December 2006
Line 65:		Line 65:
	</div>		</div>

			* identifier: <code>item</code>
			* attributes:
			** hcard:fn
			** hcard:url
			** hcard:photo
			** geo:geo
			** adr:adr
	* hlisting spec doesn't explicitly mark "item" as a class; this seems to be an oversight rather than a design decision		* hlisting spec doesn't explicitly mark "item" as a class; this seems to be an oversight rather than a design decision
	* all the attributes of the item are optional, including <code>fn</code>		* all the attributes of the item are optional, including <code>fn</code>
Line 74:		Line 81:
	</div>		</div>

			* identifier: <code>item</code>
			* attributes:
			** hcard:fn
			** hcard:url
			** hcard:photo
	* hreview doesn't explicitly note that reviewed items (that aren't hCards) may have an address or a location; this is likely an oversite because obviously seems likely that some reviewed non-locations may have these attributes; for example, a review of an amusement park		* hreview doesn't explicitly note that reviewed items (that aren't hCards) may have an address or a location; this is likely an oversite because obviously seems likely that some reviewed non-locations may have these attributes; for example, a review of an amusement park
	* <code>fn</code> (the name of the thing being reviewed!) is required; this is different than hlisting and will require some thinking about		* <code>fn</code> (the name of the thing being reviewed!) is required; this is different than hlisting and will require some thinking about

DavidJanes: /* Tier 4: specific to particular thing-types */

2006-12-08T22:11:06Z

Tier 4: specific to particular thing-types

← Older revision		Revision as of 22:11, 8 December 2006
Line 84:		Line 84:

	== Tier 3: less frequently used items ==		== Tier 3: less frequently used items ==
	== Tier 4: specific to particular ~~thing~~-types ==		== Tier 4: specific to particular item-types ==

			This is out of scope. Particular item types should be described by their own microformat that ideally would composite with [[item\|hItem]] or use it as a design pattern.

	= How this could be used =		= How this could be used =

DavidJanes: /* Tier 1: in use in microformats today */

2006-12-08T22:05:48Z

Tier 1: in use in microformats today

@@ Line 57: / Line 57: @@
 = Analysis of Examples =
-== Tier 1: in use in microformats today ==
+== Tier 1: in use in microformats (real and proposed) ==
 == Tier 2: common to 80%+ of examples ==

DavidJanes: /* DavidJanes */

2006-12-08T21:47:02Z

DavidJanes

← Older revision		Revision as of 21:47, 8 December 2006
Line 116:		Line 116:
	* We should have an "item" microformat, based on information extracted from [[hlisting\|hListing]]/[[hreview\|hReview]] in much the same was [[adr]] and [[geo]] were extracted from [[hcard\|hCard]]		* We should have an "item" microformat, based on information extracted from [[hlisting\|hListing]]/[[hreview\|hReview]] in much the same was [[adr]] and [[geo]] were extracted from [[hcard\|hCard]]
	* The top level class name will be "item"		* The top level class name will be "item"
	* There are probably a few more very common attributes that should be added; in particular, a description field		* There are probably a few more very common attributes that should be added; in particular:
	* Think about composition of items		** a description field
			** a [[uid-brainstorming\|UID]]
			* Think about composition of items using nest items; need to back this idea up with examples
	* [[item\|hItem]] should not describe the type of item; rather this comes from the context or composition		* [[item\|hItem]] should not describe the type of item; rather this comes from the context or composition
	* Microformats describing specific types of items ([[wine\|hWine]]) will composite with this ("item hwine"), in much the same way vcard is composited in hListing/hReview ("item vcard")		* Microformats describing specific types of items ([[wine\|hWine]]) will composite with this ("item hwine"), in much the same way vcard is composited in hListing/hReview ("item vcard")

DavidJanes: Removed reference to alternates, doesn't make sense

2006-12-08T21:03:22Z

Removed reference to alternates, doesn't make sense

← Older revision		Revision as of 21:03, 8 December 2006
Line 117:		Line 117:
	* The top level class name will be "item"		* The top level class name will be "item"
	* There are probably a few more very common attributes that should be added; in particular, a description field		* There are probably a few more very common attributes that should be added; in particular, a description field
	* Think about composition of items~~, perhaps using the the [[alternates]] microformat~~		* Think about composition of items
	* [[item\|hItem]] should not describe the type of item; rather this comes from the context or composition		* [[item\|hItem]] should not describe the type of item; rather this comes from the context or composition
	* Microformats describing specific types of items ([[wine\|hWine]]) will composite with this ("item hwine"), in much the same way vcard is composited in hListing/hReview ("item vcard")		* Microformats describing specific types of items ([[wine\|hWine]]) will composite with this ("item hwine"), in much the same way vcard is composited in hListing/hReview ("item vcard")

DavidJanes: /* DavidJanes */

2006-12-08T20:52:47Z

DavidJanes

← Older revision		Revision as of 20:52, 8 December 2006
Line 117:		Line 117:
	* The top level class name will be "item"		* The top level class name will be "item"
	* There are probably a few more very common attributes that should be added; in particular, a description field		* There are probably a few more very common attributes that should be added; in particular, a description field
			* Think about composition of items, perhaps using the the [[alternates]] microformat
	* [[item\|hItem]] should not describe the type of item; rather this comes from the context or composition		* [[item\|hItem]] should not describe the type of item; rather this comes from the context or composition
	* Microformats describing specific types of items ([[wine\|hWine]]) will composite with this ("item hwine"), in much the same way vcard is composited in hListing/hReview ("item vcard")		* Microformats describing specific types of items ([[wine\|hWine]]) will composite with this ("item hwine"), in much the same way vcard is composited in hListing/hReview ("item vcard")

DavidJanes: What this microformat should look like

2006-12-08T20:48:21Z

What this microformat should look like

← Older revision		Revision as of 20:48, 8 December 2006
Line 114:		Line 114:
	== [[DavidJanes]] ==		== [[DavidJanes]] ==

	* We should have an "item" microformat		* We should have an "item" microformat, based on information extracted from [[hlisting\|hListing]]/[[hreview\|hReview]] in much the same was [[adr]] and [[geo]] were extracted from [[hcard\|hCard]]
	* This is extracted from hListing/hReview in much the same was [[adr]] and [[geo]] were extracted from [[hcard\|hCard]]		* The top level class name will be "item"
	* The top level class name ~~should~~ be "item"
	* There are probably a few more very common attributes that should be added; in particular, a description field		* There are probably a few more very common attributes that should be added; in particular, a description field
	* ~~Future microformats~~ describing specific types of items (hWine) will composite with this ("item hwine"), in much the same way vcard is composited in hListing/hReview ("item vcard")		* [[item\|hItem]] should not describe the type of item; rather this comes from the context or composition
	* ~~It probably should apply to non-physical things also since this is very general~~		* Microformats describing specific types of items ([[wine\|hWine]]) will composite with this ("item hwine"), in much the same way vcard is composited in hListing/hReview ("item vcard")
	* The initial version of this spec should not be ~~too complicated (avoid deep analysis and leave that~~ for ~~new microformats, possibly backmerging)~~		* [[item\|hItem]] should be simple and concise and not be a general purpose dumping ground for attributes
	* Updated: 2006-11-18		* Updated: 2006-12-08

	== Andy Mabbett ==		== Andy Mabbett ==