abstract-properties: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
m (Reverted edits by ErlirAcmon (Talk) to last version by Tantek) |
||
| (7 intermediate revisions by 4 users not shown) | |||
| Line 7: | Line 7: | ||
Rather than abstracting to "mandatory" / "nice-to-have", I think it is worth seeing if such a property is in the 80/20 of those containing microformats first, and designing accordingly. | Rather than abstracting to "mandatory" / "nice-to-have", I think it is worth seeing if such a property is in the 80/20 of those containing microformats first, and designing accordingly. | ||
Creating abstract generic properties in a vacuum (or before / without constraining them with specific | Creating abstract generic properties in a vacuum (or before / without constraining them with specific [[examples]] per the [[process]]) will likely result in them either being overly watered down, or overly complex in order to handle "possible cases" instead of "actual cases". | ||
Thus abstract properties tend to be an instance of [[rejected-formats]]. | |||
Latest revision as of 22:10, 20 December 2008
Abstract Properties
Some notes from an IRC conversation 20070118.
Regarding a possible abstract "mandatory" property:
Rather than abstracting to "mandatory" / "nice-to-have", I think it is worth seeing if such a property is in the 80/20 of those containing microformats first, and designing accordingly.
Creating abstract generic properties in a vacuum (or before / without constraining them with specific examples per the process) will likely result in them either being overly watered down, or overly complex in order to handle "possible cases" instead of "actual cases".
Thus abstract properties tend to be an instance of rejected-formats.