RFC: Discover schedule.xml URL/location about giggity HOT 8 OPEN

Woo, thank you for the very detailed proposal! Yes, this is an interesting idea. Let me try to summarise my thoughts..

First: Giggity picked up Markwon a few versions ago and I think it could help here. https://noties.io/Markwon/docs/v4/html/ Though I wonder whether just feeding HTML to a streaming XML parser would also work? No need for it to build a DOM tree, a streaming XML parser is probably very unpicky as well, I'd expect?

For the MIME-type .... So theoretically maybe some day the standard format could become JSON-based? You'll know that better than me obviously :) Just searching for a <link type=application/xml> and then checking whether the href= points at something we can parse is a way, but I'd love something more exact, either indeed by claiming a MIME-type for this (application/giggity+(xml|json|yaml(ugh, please no BTW))?), or by using another tag (title= is available? Though I guess that theoretically needs to be localised..).

Nit: It'd probably be cool if the link could be included not just on the schedule page of the conference but also the frontpage or perhaps just ~all of them? Since the user is going to have to manually enter/copypaste a URL, it'd be cool if it could be as simple as typing fosdem.org. But if the link is on more pages, would rel=alternate still be accurate?

I do have deduplication on my mind a bit.. Very important that we don't end up with two entries in the chooser menu for example, which could happen if the conference later submits a menu.json entry. And there's the interesting case of FOSDEM who finally switched over to Pretalx this year AFAIK, but their published schedule XML file was not a straight Pretalx export but something they generated themselves that looked more closely like their old file format (roughly Pentabarf so still pretty similar, just without some of the (recently) added fields). Not sure what to do here, probably hard to really get this right. Merging may be feasible if IDs/GUIDs match, but still an odd feature.

I started reintroducing an id= tag in the menu.json file to at least support rare cases where schedule files get moved around, but that won't help here either probably.

¹ Also, just gotta say, as maintainer of pretalx, I love that giggity exists and recommend it to events all the time. Thank you for making and maintaining it.

Thank you and you're welcome! It's an interesting hobby when the daytime job is more SRE-like. I'm sad that the "each event their own app" model seems to have won, but I'll keep doing what I think is better. :)

And obviously thank you for Pretalx!

from giggity.

Theoretically maybe some day the standard format could become JSON-based?

The XML standard is maintained by c3voc and their validator, who also provide a JSON schema for frab's (and hence pretalx's etc) JSON export. They should include largely the same data, so you could have a go at that instead? I don't mind either way, pretalx implements both APIs, and if we include one <link> tag, we may as well (and probably would) include both.

but I'd love something more exact, either indeed by claiming a MIME-type for this (application/giggity+(xml|json) or by using another tag (title= is available?)

Sure, that would work just as well. I think I have a soft preference for using application/frab+(xml|json), as the format is mostly known for (and maintained via) frab, and hardcoding Giggity there feels a bit exclusive, but tbh it doesn't really matter and would just become a de-facto standard either way (even without a formally registered mime type, which I don't think would be necessary).

But if the link is on more pages, would rel=alternate still be accurate?

I think so, yes, or at least I had intended it that way. As long as the format is sufficiently specific, that'd be like providing the RSS feed link on all pages of a website, which is also commonly done.

(Re: deduplication: I think the whole menu.json thing is a secondary concern, as we can just as well start without it, and you can decide at any point to support it or not, imo! If conferences provide their own modified export, they could link to that instead, too, so hopefully there wouldn't be too much duplication going on.)

Going to tag @saerdnaer here, as he's involved with the C3VOC side / the schedule.xsd and JSON schema, and may have ideas or opinions.

from giggity.

I would prefer application/schedule+(xml|json) – in my option the format has became independent from frab/pentabarf... And as far as I understood FOSDEM and CCC / Congress will both use pretalx – so it's makes not really sense to add new schedule format features to frab source code...

from giggity.

Sorry, yes obviously, generic has my preference too, typed that response too fast apparently. :)

I'd say that "schedule" is too generic though? :( That'd be the benefit of picking for example "frab": With most of us that's a pretty good descriptor for a file format describing conference schedules. Just "schedule" could still be anything else calendar'y.

For the duplication, you may have a good guess on how (un)likely my worries are? If folks build their own format like how FOSDEM did it, oh well oops... but hopefully Pretalx at least by default doesn't have 5 different canonical links pointing at the same XML content? Either way, yeah I'll think that one through later on.

from giggity.

I'd say that "schedule" is too generic though?

Yeah, +1 on that. Claiming a MIME type of "application/schedule+xml" would be to ballsy imo. "frab" has the advantage of being an established tool – as an alternative "application/c3voc+xml" might work, as VOC are maintaining the format definition?

CCC / Congress will both use pretalx

Huh, good to know. That's news to me.

from giggity.