#microformats 2018-07-22

2018-07-22 UTC
iwaim, KartikPrabhu, tantek__, tantek and barpthewire joined the channel
#
@lockedowndesign Metadata, Part 2: Microformats #seo https://www.lockedownseo.com/metadata-microformats/?utm_source=ReviveOldPost&utm_medium=social&utm_campaign=ReviveOldPost (twitter.com/_/status/1021027512493793281)
#
@AliAbdullahsam1 RT @lockedowndesign: Metadata, Part 2: Microformats #seo https://www.lockedownseo.com/metadata-microformats/?utm_source=ReviveOldPost&utm_medium=social&utm_campaign=ReviveOldPost (twitter.com/_/status/1021028562063839232)
[jgmac1106] joined the channel
#
@jgmac1106 RDFa vs microformats from Evan Prodromou: http://web.archive.org/web/20140704091616/http://evan.prodromou.name/RDFa_vs_microformats (twitter.com/_/status/1021047656964067328)
snarfed, [chrisaldrich], [snarfed], jackjamieson, [kim_landwehr], [kevinmarks], indy and barpthewire joined the channel; snarfed left the channel
#
jmac Ahoy. I have a question about the microformats parsing spec.
#
jmac At http://microformats.org/wiki/microformats2-parsing#parsing_for_implied_properties, I read "if no explicit "name" property, and no other p-* or e-* properties, and no nested microformats, then..."
#
jmac I took this to mean that my parser should follow the subsequent instructions if and only if the h-x item it's in the middle of constructing doesn't have any p- or e- properties defined within it, by way of sub-elements.
#
Loqi [Tantek Çelik] microformats2 parsing specification
#
jmac As such, I would expect the h-geo item defined at https://github.com/microformats/tests/blob/master/tests/microformats-v2/h-geo/abbrpattern.html to have no implied name, because it does indeed contain a couple of p- properties... right?
#
jmac But, according to https://github.com/microformats/tests/blob/master/tests/microformats-v2/h-geo/abbrpattern.json, the parser should in fact read an implied name out of the element's text content.
#
jmac Therefore, I am confused. (And I suspect I don't understand what "no other p-* or e-* properties" means, perhaps?)
#
sknebel tests aren't up to date
tantek__ joined the channel
#
jmac I hear a lot of that, and yet they have done a good job leading me down the right path, so I tend to trust them.
#
jmac Are they known to be out of date in this particular aspect?
#
jmac Coz when I remove the "no other properties" restriction from my code, suddenly a ton of failing tests pass.
#
jmac To be clear, I'm very interested in helping to pinpoint how the tests don't match the spec, and perhaps assisting in updating them. This is merely the first question I have of several from my most recent dive into the spec. :)
#
sknebel I know what the spec intends here, since I helped formulate that change recently
#
sknebel and since its a relatively young change, it's not surprising the tests don't reflect it yet
#
sknebel for reference, here's the spec discussion https://github.com/microformats/microformats2-parsing/issues/6
#
Loqi [tantek] #6 reduce instances when p-name is implied
#
jmac I see. Well, if my original read of the spec as currently written is correct, then several of the tests need updating to have implied-name properties removed from the target JSON files... that's not something I'd feel comfortable pull-requesting without further feedback
#
jmac But that's good to know, thanks
[kim_landwehr] joined the channel
#
sknebel feel free to make a PR, it'll be reviewed by someone before it is merged
#
jmac Oh, well, sure. :) I just want to make sure I'm correct in my read though -- *is* it the case that, with https://github.com/microformats/tests/blob/master/tests/microformats-v2/h-geo/abbrpattern.html, there simply shouldn't be an implied name property at all?
[kevinmarks] joined the channel
#
sknebel yes
#
sknebel and if it is a nested microformat (which a geo would often be), then "else use the parsed property value per p-*,u-*,dt-* parsing respectively" triggers for the "value" (from this section, near the bottom http://microformats.org/wiki/index.php?title=microformats2-parsing#parse_an_element_for_class_microformats
#
Loqi [Tantek Çelik] microformats2 parsing specification
KartikPrabhu joined the channel
#
jmac I'm afraid I don't really understand that one. Does an example document exist?
#
KartikPrabhu jmac: you can try out examples here http://pin13.net/mf2-dev/
#
jmac Ah, great... thanks
#
KartikPrabhu or for the python parser (up-to-date) here https://kartikprabhu.com/connection/mfparser
#
sknebel jmac: http://pin13.net/mf2-dev/?id=20180722211616342
#
sknebel I meant the "value" on the "location" property
#
sknebel since there isn't a p-name on the h-geo,for the value the content of the h-geo is parsed as if it were a normal p-property
tantek joined the channel
#
KartikPrabhu the tests repo should have a warning that it is out of date!
#
KartikPrabhu I don't think any up-to-date parser uses them
#
jmac It's the test resource I've been building my Perl-based parser off of, haha. (And it's been updated as of 4 month ago, so you'd *think*...)
#
jmac But yeah the PHP tool is great for quick development, thanks KartikPrabhu
#
jmac It makes me feel a lot more confident about submitting some PRs for the test repo too.
#
KartikPrabhu right I would test against phpmf2 or mf2py since they have been generally more on top of the spec stuff
#
sknebel and you can of course always ask here, and I'd encourage you to put a similar webform for your parser online
#
sknebel we (at least Zegnat and me ;)) are happy to try find issues once you feel like you want external help finding them
#
jmac sknebel: That's not a bad idea at all
#
jmac I will always remember fondly the day a few months ago I announced on #indieweb-dev that I added a webmention form to my blog, and you immediately nerve-pinched it with input that made it keel right over. (Probably submitting a page's URL to itself.)
#
jmac Moving on... I'd like to ask about http://pin13.net/mf2-dev/?id=20180722214405800 which doesn't seem to agree with http://microformats.org/wiki/value-class-pattern#Date_and_time_parsing (nor does the python mfparser output)
#
sknebel nothing in that example is value-class-pattern?
#
jmac The spec, if I'm reading it right, says that after the parser recognizes a datetime, it always presents it as [date] [space character] [time] [offset], omitting any chunks it doesn't know about
#
jmac oh, hm
[kiai] joined the channel
#
jmac So all those datetime parsing rules apply *only* when a datetime comes out of a value-class pattern, otherwise the parse just naively passes the given datetime value through with no processing?
#
tantek__ KartikPrabhu: rather than a warning on the test repo (which sounds like it would encourage neglect!), how about filing an issue regarding the out of date test?
tantek joined the channel
#
tantek__ jmac, yes, though there are proposals to make them always apply
#
tantek__ just like the URL parsing rules always apply for u-* properties
#
jmac Grump
#
tantek__ can't recall the issue # offhand
#
jmac I sunk a lot of time today into accounting for all these crazy exceptions, ha ha blah.
#
tantek__ jmac, they're crazy real world publishing behaviors 😂
#
jmac I don't doubt it!
#
jmac And all this work still does apply for VCPs. I will just refactor it like a grownup
[kevinmarks] joined the channel
#
gRegorLove_ takes a look at implied name in mf tests
#
gRegorLove_ KartikPrabhu, php-mf2 uses microformats/tests as a secondary test suite, though it's optional and not part of CI
#
KartikPrabhu sure "uses" as in not actually following them
#
gRegorLove_ I don't follow
#
[kevinmarks] Also mf2py will run them if they're in an adjacent directory
tantek joined the channel
#
KartikPrabhu gRegorLove_: as in if phmf2 fails a test from the test repo what happens?
#
tantek jmac, if you have a moment, check https://github.com/microformats/microformats2-parsing/issues for previous issues re: VCP etc.
#
tantek otherwise worth filing an issue for all dt-* parsing to follow VCP date & time parsing rules
#
jmac tantek: Thanks, I'll make a point to browse it. I'm got gonna put my foot down over the datetime stuff though (and I've already refactored my library so it doesn't care anymore, ha ha.)
#
jmac *not gonna
#
jmac I would like my thing to work like everyone else's before I start cheekily suggesting changes
#
tantek__ just making sure the good questions you're asking are properly answered!
#
jmac roger that
#
jmac I <3 the chat but i'll use this when applicable
#
tantek__ even if all we end up doing is clarifying documentation, clearly that's an area we can improve.
#
gRegorLove_ KartikPrabhu, it shows the failure, actual parse, and expected parse
#
jmac I can ask here and now: Would you rather see me file an issue about the outdated test repo, or submit a pull request to it?
#
gRegorLove_ I think this is the issue tantek__ referenced, jmac: https://github.com/microformats/microformats2-parsing/issues/12
#
KartikPrabhu right but that does not mean phpmf2 failed, it is more like testing the test suite
#
Loqi [tantek] #12 should dt-* parsing do date and time parsing for all values?
#
tantek__ yes that one!
#
tantek__ jmac feel free to add your experience, thoughts, opinion to ^^^ (issue 12)
#
gRegorLove_ jmac: I'm looking through the tests for the implied name change currently. I think an issue is fine; I can reference that.
tantek joined the channel
#
jmac Thanks, but I really don't feel like I have a dog in that particular fight. I'm more interested in either updating the test repo at microformats/tests, or otherwise marking it as deprecated or whatever
#
gRegorLove_ Definitely not deprecated
#
jmac I was only briefly cranky about the datetime stuff an hour ago when I thought that all my parsing code was for naught, but then I realized that it definitely still applies when there *is* VCP, and thus was I mollified.
#
gRegorLove_ Looks like one of the tests just surfaced an issue in php-mf2. http://pin13.net/mf2/?id=20180722223715127 `photo` should only be in the child h-card
#
gRegorLove_ That might be this open PR though: https://github.com/indieweb/php-mf2/pull/177
#
Loqi [gRegorLove] #177 Fix XPaths used in implied photo parsing
#
gRegorLove_ Yeah, pretty sure that's the case
#
[kevinmarks] Submitting PRs to the tests repo seems like a good idea
#
gRegorLove_ Yeah, I'm working on one for the implied name changes
#
@schnarfed ↩️ @jhauge an alternative answer is, the data standard is http://microformats.org/wiki/microformats2 (twitter.com/_/status/1021165453807243265)
#
tantek__ gRegorLove++
#
Loqi gregorlove has 37 karma in this channel (262 overall)
#
gRegorLove_ Submitted: https://github.com/microformats/tests/pull/86
#
Loqi [gRegorLove] #86 Remove implied name per spec update
#
KartikPrabhu sknebel: for your ideas https://github.com/microformats/mf2py/issues/108#issuecomment-406905058
#
Loqi [kartikprabhu] attempted a fix here https://github.com/kartikprabhu/mf2py/commit/8a206624ba4471c1b7b0725a75261b697c0458f3 but this fails the crucial test https://github.com/kartikprabhu/mf2py/blob/experimental/test/test_parser.py#L592 and I have no idea why or h...
#
gRegorLove I don't have permission to close microformats/tests issues. Commented that this one can be closed: https://github.com/microformats/tests/issues/82
#
Loqi [cleverdevil] #82 Remove no longer relevant tests
#
KartikPrabhu Zegnat: since you like updating specs https://github.com/microformats/microformats2-parsing/issues/24#issuecomment-403346296 ;)
#
Loqi [kartikprabhu] At IWS 2018 (https://indieweb.org/2018/microformats#parsing_.2324) It was accepted to treat `<noscript>` as a `<div>`. By this proposal the answer to all five questions posed in the beginning (https://github.com/microformats/microformats2-parsing...