On Thu, Jan 14, 2021, at 19:07, Mathieu Pasquet wrote: > thhus projects not publishing the file would be less accessible, which > is the current status).
This is one of the reasons I am furious that we're seriously considering adopting this format for use on the website. This is absolutely not okay. > Second, I do not believe for a second that someone as computer > literate as an XMPP client/library/server author would have trouble > with an RDF XML representation. Well lucky you, but I have tried to do this multiple times and have no idea how to even verify that what I have done is correct, or have ended up finding out that bits of it aren't correct later. I'm sure that with a great amount of effort I could figure it all out, but that's exactly the problem, I shouldn't have to put in effort just to write up some simple metadata. > I do not mean to say that understanding the whole "semantic web" > technologies is easy or fast, but it is not actually required to write > a proper DOAP file. How can I even confirm that my DOAP file is correct? How do I discover the various properties that I can put in it? So far I've just been linked to various giant XML blobs which is not helpful. > (slightly offtopic, but the concept of RDF/Turtle/N- Triples was > introduced as a simple representation even before learning a > programming language in my first year of university) I don't know what any of those things are (except for some vague knowledge that RDF is a thing because we've been talking about it), but if you have to have it introduced at university it's too complicated for use describing simple metadata. They certainly didn't teach us a bunch of random XML concepts in school, thank goodness. > I would still argue that DOAP is the most widely-used and widely- > supported format across the board, given that the alternative is > something hand-rolled with the same fields that we need to write > tooling for and maintain. We apparently have to maintain a spec and custom namespaces either way and integrate with a complicated format. That's more work than just outlining a few standard key-value names and throwing them in an XML file. We can write tooling for the new thing if we want (and I will do it if people really want it), but if you need tooling just for some metadata you're already doing it wrong, which is the point I'm trying to make. If it's a normal XML format without tons of namespaces and schema imports and what not we don't have to do anything but pull out a few values and stick them up on the website which is trivial to do in JavaScript or Python (which I think the website's generator is written in, IIRC). What's not trivial is pulling in and validating various schemas. > There is a standard format, there are tools to query it, tools to > validate it, and writing it is not hard (and there are very few things > with bikeshedding potential in it). I'm just going to repeat this again because it's important and I believe a valid criticism: if I have to learn a bunch of tooling just to put a bit of metadata on my website it's over engineered and needs to stop. > I agree that the protoxep state is still a good moment to raise > serious objections or propose alternatives, but “I do not like it and > here is the same thing in json with no well-defined semantics and > please write new tools for it and maintain it” is not a stance I can > take very seriously. I presented an XML format too, I don't really care what it is, let's just define a few key value pairs and say "here's the info you need, here's an XML (or whatever) example". It's good enough. > I also fail to see how using this format would be “harmful” It's over complicated and you're putting all the burden on the people writing it. You will lose projects who would otherwise provide valid metadata because they'll try, it will be incorrect, and they'll give up, or they'll take a look at the "documentation" I keep being linked (a giant blob of XML) and not do it in the first place. Complexity is a problem, and this is about as complex as you can get to just store a few tiny bits of metadata. —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
