#[KevinMarks]Hm, part of the point of the mf2 changes was not needing to update parsers for new types or fields. Maybe we need to add some tests to reflect that (and also the field and type name filtering rules)
#sknebel!tell jacky "so a test failed b/c it's mentioned h-org as a type (the parser does hard failures on unrecognized types)" <- there is no concept of "recognized" types in mf2 parsing! don't do that please
#[tantek]This is why I think h-org is in there, there's no spec for it
dovedozen[d] and P1000[d] joined the channel
#[KevinMarks]we added the constraints on field names to avoid the utility class false positives, but I don't think we have negative test for those `The "*" for root (and property) class names consists of an optional vendor prefix (series of 1+ number or lowercase a-z characters i.e. [0-9a-z]+, followed by '-'), then one or more '-' separated lowercase a-z words.`
#[KevinMarks]maybe we need some more abstract parser tests to catch both novel type and property strings, but also have some that should not be parsed (eg my mixed case schema alike ones shouldn't parse now http://www.kevinmarks.com/microformatschema.html )
#Loqi[Kevin Marks] Microformats 2 and Schema 2015-06-30
#Loqijacky: sknebel left you a message 8 hours, 15 minutes ago: "so a test failed b/c it's mentioned h-org as a type (the parser does hard failures on unrecognized types)" <- there is no concept of "recognized" types in mf2 parsing! don't do that please
#jackyup to 78 out of 95 tests (the microformat tests are a smaller amount - like 6 less, I have some checks for value class parsing)
#jackyallowing for a distinction between a vendor extension, experimental and conventional (I guess?)
#jackyit's mainly decorative for the parser but it helps with serialization from MF2+JSON to the concrete types in Rust (like which ones should have ptd run on it, etc)
ur5us and jamietanna joined the channel
#jackylol my parsing of h-recipe keeps thinking that `Fat: 3.4g` is a URL