- Output type could be implied from
a/@typerather than explicit?. Currently the output type is explicit in a
typeattribute, but either the output could just be taken from the anchor, or if it is duplicated visibly, perhaps it should match the MIME type rather than using strings? e.g.
Jump to navigation Jump to search
Revision as of 16:43, 1 July 2009 by GeorgeBrock (Possible benefits of retaining a separate assertion method for dates)
Issues against test-fixture. Note that this poshformat has not been through the microformats process and serves a funcational purpose for the microformats test suites work.
- Represent history of changes using hAtom rather than hCalendar. It strikes me that hAtom 0.1 would be a more appropriate format for a changelog than hCalendar.
- Consider separating *Unit asserts from custom asserts. Although the normalisation of Geo and Dates is a very useful enhancement, they may not be essential (since ISO dates can be compared somewhat reliably as strings, and co-ordinates compared to the same precision as they appear in the source). This seems desirable for simple conversion into something like JUnit, without being dependent on additional functions.
- Some parsers discard the ISO string in favor of another date representation (e.g. MoFo, Sumo). When testing these parsers, equality assertions for dates would require some additional logic to compare the parsed value to the asserted value. For parsers that output dates as a generic data type (e.g. as an integer containing a UNIX timestamp) detecting when to apply this date-specific logic would be non-trivial and could require knowledge of which µf fields should contain dates, undermining the design goal of self contained tests. Keeping a separate equality assertion method for dates could therefore reduce complexity overall. - GeorgeBrock 16:43, 1 July 2009 (UTC)