[Standards] Proposed XMPP Extension: DOAP usage in XMPP
sam at samwhited.com
Thu Jan 14 19:24:23 UTC 2021
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
> 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
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.
More information about the Standards