#microformats 2023-03-26

2023-03-26 UTC
[tantek], [pfefferle], ur5us, [manton], dwag, [jeremycherfas], [KevinMarks], IWSlackGateway, k1, [jamietanna], axiomeval, btrem and [snarfed] joined the channel
#
[snarfed] mf2++ for making all property values lists
#
Loqi mf2 has 1 karma over the last year
#
[snarfed] Way easier to work with than the AS2 I'm currently fighting where most fields can be either strings, objects, or lists
#
[KevinMarks] Conneg at the field level
#
[snarfed] Oof yeah
[aciccarello] and [tantek] joined the channel
#
[tantek] [snarfed] that was a hard earned lesson, and ironically is still "unpopular" with many JSON devs because they don't want to have to look for the first item in a list
#
capjamesg Why are lists > strings for mf2?
#
[tantek] Because you never know when a property can (eventually) have multiple values
#
[tantek] always a list > > sometimes a string, sometimes a list
#
[tantek] The latter takes more code than the former
#
[tantek] And if you start with a data format design with only strings, it will almost always evolve to have strings or lists.
#
[tantek] [snarfed] contrast with jf2
#
[snarfed] oof yeah, skimming https://jf2.spec.indieweb.org/, sounds like many jf2 properties can also be strings, objects, or lists 😐
[timothy_chambe] joined the channel
#
[KevinMarks] Well, they become "children" when they're lists.
#
[KevinMarks] The mf2 thing of lists by default and a "value" fallback for objects is good
#
[KevinMarks] The original idea of there always being a "name" didn't quite work out
#
[tantek] [snarfed] the challenge is that so many proprietary JSON APIs (and even other specs like AP) seem "easier" because of the "direct" string access on many properties, so developers have this expectation that it should always be that "easy" but that's because they forget that proprietary APIs change & expand in very awkward & ugly ways that would NOT work well for a standard protocol or format
#
[tantek] also I believe aaronpk pushed for jf2 as well, in order to "simplify" his own code (I may be misremembering the exact use-case) and probably has an opinion about this trade-off
#
[snarfed] yup, understood. iirc one of the big jf2 motivations was that traversing children and finding the item you want in an mf2 parse tree isn't as easy, and can vary widely across sites, so standardizing that helped
#
[snarfed] which is true, and a separate problem from field types
ur5us joined the channel
#
[tantek] Yes, object traversal (hierarchy vs flat) is different from field plurality
#
[tantek] There's something in there between "ease of publishing" and not ease of parsing, but rather ease of "data structure reasoning" for consuming code
#
[tantek] Might be worth exploring more instances of that, along with well defined transforms from one to the other, so e.g. libraries could be written to do those transforms instead of every consuming app having to.
#
[tantek] I have a feeling that's what's been motivating Barnaby and capjamesg's "helpers" and "utils"
#
[KevinMarks] You do end up writing recursive parsers.
#
[KevinMarks] I just realised that GraphQL is conneg at the structure level