Hello Goffi
Internet Content Types have proven themselves to be a very successful method to
promote interoperability on the web. Why it it would be just like "saying
goodbye to the idea of interoperability" is a mystery to me.
That you don't like Markdown is apparent ("good alternative (i.e. not
Markdown)"), and is just a personal oppinion, which is OK. But that's not the
point. There are now two proposals that stem from the same need: The desire to
be more flexible when it comes to sending different types of content, and have
an accepted (interoperable) way to annotate what content is being transmitted.
The question the XSF needs to ask itself: Does it want to act as a conduit to
help XMPP developers find interoperable ways to perform what they want to do,
or should indivudual members, based on personal opinions, block such efforts?
Just because you don't want do communicate Markdown, should it be permissible
for you to block others who wants to? And a followup: Those that want to
communicate Markdown, how should they find an interoperable manner to do so?
Inside, or outside of the XSF?
Best regards,
Peter Waher
> Moving from a well working thing to an syntax is already something I'm not
> really supporting even if I could follow if we have a good alternative (i.e.
> not Markdown), but having an open bar and letting any content type like you
> proposed is just saying goodbye to the idea of interoperability (and the
> sanity of clients developers), and it was a true relief to see a veto on this
> one.
> > Hello
> >
> > A year and a half ago I proposed a XEP: "Content Types in Messages" [1],
> > solving the issue of describing and annotating what type of content is sent
> > in messages. At the time, many objected, since they did not see the value
> > of this annotation.
> >
> > Now, the interest seems to have been awakened again, with a new proposal:
> > "Body Markup Hints" [2]. Both seem to be based around markdown, so there's
> > an obvious common interest and common ground.
> >
> > What I wonder is: Why don't we collaborate on this? There are already
> > implementations of [1]. It solves the issue using a paradigm that matches
> > what is elsewhere used on the internet (Content Types). Why invent
> > something new, and not renew the application of the original proposal? And
> > if there's something missing, the proposal can be updated, and the author
> > list increased.
> >
> > Best regards,
> > Peter Waher
> >
> > [1] https://github.com/xsf/xeps/blob/master/inbox/content-types.xml
> > [2]
> > https://github.com/xsf/xeps/pull/529/commits/4bc652eb7cefb5489f67f31a3eda20
> > 21cba85783
>
> Hi Peter,
>
> I was one of those objecting, and I wasn't objecting because I "did not see
> the value of this annotation", but because I thought (and I'm still thinking)
> that it's a terrible solution.
>
> Moving from a well working thing to an syntax is already something I'm not
> really supporting even if I could follow if we have a good alternative (i.e.
> not Markdown), but having an open bar and letting any content type like you
> proposed is just saying goodbye to the idea of interoperability (and the
> sanity of clients developers), and it was a true relief to see a veto on this
> one.
>
>
> Cheers
> Goffi
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
