Despite having searched extensively, I've yet to find a conference metadata file format that is even in the ballpark of what I would consider to be acceptable as a standard. Moreover, all of the ones I've found have horrible implementation/app-specific design compromises. I'm a very strong believer in structured data, and in designing the schema such that it can be used flexibly and extended when necessary. Pentabarf's XML may come closest to what I'm looking for, but it has a lot of "smell" that makes me think it was developed organically, without significant up-front design. That's the same problem we have with the legacy HackerTracker json bundle: it makes a lot of assumptions that are simply untrue for many events. The data could be coerced into it, but that leads to suffered user experience.
The data publication schema must be a file specification, and not an API. Web APIs may also be employed in any part of ngccs, but the "essential conference data" (except for referentially-included binary payloads, I suppose) must be able to be published to, and consumed by, clients in a prescribed file format. This has a number of benefits:
absolutely decreases the number of round-trips a request might need to take for bulk-data-loading as compared to REST
makes the exact same file(s) available for long-term archive, along with the unmodified client apps that were used
reduces your web service requirements all the way down to "ability to host a static file"
The biggest drawback of this, as I currently see it, is that structure must be included in the schema, and logic must be included in the apps, for bringing the client up-to-date, checking for new content, and patching the client knowledge as a result of content updates.
Components of ngccs that are inherently interactive, such as client submissions for a request for an ad-hoc event to be created, or summoning help, or reporting a COC violation, of course require that an API be used, and would not be considered "essential conference data".
Despite having searched extensively, I've yet to find a conference metadata file format that is even in the ballpark of what I would consider to be acceptable as a standard. Moreover, all of the ones I've found have horrible implementation/app-specific design compromises. I'm a very strong believer in structured data, and in designing the schema such that it can be used flexibly and extended when necessary. Pentabarf's XML may come closest to what I'm looking for, but it has a lot of "smell" that makes me think it was developed organically, without significant up-front design. That's the same problem we have with the legacy HackerTracker json bundle: it makes a lot of assumptions that are simply untrue for many events. The data could be coerced into it, but that leads to suffered user experience.
The data publication schema must be a file specification, and not an API. Web APIs may also be employed in any part of ngccs, but the "essential conference data" (except for referentially-included binary payloads, I suppose) must be able to be published to, and consumed by, clients in a prescribed file format. This has a number of benefits:
The biggest drawback of this, as I currently see it, is that structure must be included in the schema, and logic must be included in the apps, for bringing the client up-to-date, checking for new content, and patching the client knowledge as a result of content updates.
Components of ngccs that are inherently interactive, such as client submissions for a request for an ad-hoc event to be created, or summoning help, or reporting a COC violation, of course require that an API be used, and would not be considered "essential conference data".