[Standards] Proposed XMPP Extension: DOAP usage in XMPP
mathieui at mathieui.net
Thu Jan 14 19:07:38 UTC 2021
On 13.01.2021 19:41, Sam Whited wrote:
>I do not believe this is an appropriate technology whether it's an
>existing specification or not. It's just too complicated.
>On Wed, Jan 13, 2021, at 19:35, Dave Cridland wrote:
>> On Wed, 13 Jan 2021 at 18:24, Sam Whited <sam at samwhited.com> wrote:
>> > I'd like to recommend that we do not publish this spec in its
>> > current form. The XML community has the tendency to over-engineer
>> > everything to try and reuse schemas as much as possible which just
>> > makes things more difficult for no reason. This is a handful of
>> > simple key/value pairs, it doesn't need to use RDF or whatever the
>> > "schema" prefix means.
>> > If this spec is moved forward please consider either adding a JSON
>> > representation since this is mostly for the web and is effectively
>> > just a set of key-value pairs which probably makes JSON a better
>> > format for storing it, or a simplified XML representation that can
>> > be completely defined in this document and exists in a single
>> > namespace.
>> I was under the impression that DOAP was an existing deployed
>> specification, and that the use of RDF/XML wasn't unexpected.
>> In particular, it appears that both Mozilla and PyPI seem to use it,
>> so assuming reuse of existing standards is our thing - and
>> presumably that is exactly our thing - then use of DOAP seems like
>> the right choice.
>> Standards mailing list Info:
>> https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards-
>> unsubscribe at xmpp.org
I am sorry you do not like it, Sam, but here are a few things I would
like to mention.
First, this format has been talked about for over three years now ,
without anyone raising a concrete objection. It has taken a while not
because it is too complicated or impossible to get right, but because
Link Mauve wanted to have good integration with the XSF website
(and therefore be sure that the information in enough for this
purpose), and because it was not at the top on the todo list.
At the time , you did say that they did not want to require
this format to get listed on xmpp.org, and I do not think there is
such a a plan right now (the plan however is to allow easier discovery
using the metadata listed therein, thhus projects not publishing
the file would be less accessible, which is the current status).
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. 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. (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)
Third, I can agree that support for DOAP is not where it ought to be
in most software projects, in part because SPDX  has been defined to
describe packages instead of projects and part of the DOAP users
jumped ship because that was closer to their usecase. SPDX does
refer to DOAP for several properties though.
There is also a clear lack of activity in the DOAP project, and while
one of the authors has approved the changes submitted by Link Mauve,
the standard had not moved for a very long while and thus there is
no automated process to echo the changes back to the schema listed
on the website.
Additionally, Pypi did not bring back DOAP export when writing Warehouse
(the replacement of the legacy web application), mostly due to a lack
of interest . On the other hand, our use case of the format is
well-defined and fits.
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. 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 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
I also fail to see how using this format would be “harmful”, as the work
involved from a software author point of view is definetly not the format
but gathering the XEP implementation status, versions, and history
(all of which can be done over time). Unless we somehow expect it to be
trending Hacker News and want to premptively shield ourselves from
kneejerk comments about XML.
More information about the Standards