[Standards] Proposed XMPP Extension: Styling
dave at cridland.net
Tue Nov 7 20:10:19 UTC 2017
On 7 November 2017 at 15:16, Marvin Gülker <m-guelker at phoenixmail.de> wrote:
> Am 06. November 2017 um 15:29 Uhr -0600 schrieb Sam Whited <sam at samwhited.com>:
>> > Not using something XML-based in a XEP's format
>> > also creates a precedence case from which we don't know where else it
>> > will come back at us when other XEPs are made.
>> I didn't understand this, sorry, could you please rephrase it or attempt
>> to clarify?
> Until now, XMPP is based on XML throughout all XEPs (that I'm aware
> of). This now introduces markup that's not XML for the first time,
> requiring a specific parser for it. What I'm saying is just that in
> future XEPs, it will be much easier to refer to this one and say "hey,
> we already have a XEP that's not based on XML, so what's wrong with
> this?". Consequently, XMPP clients are going to accumulate a plethora of
> parsers for different formats over time then.
An XMPP client typically has an ASN.1 DER parser, as well as XML, and
countless other parsers for microformats you've forgotten we use
because they're buried deeply. DNS, perhaps, or various SASL
mechanisms. I'm pretty sure that a JSON parser is probably quite
common, too (POSH, for example, needs a JSON parser). You might even
The difference here isn't that it's another parser, it's that its a
new "home grown" syntax to parse. We don't do those often - XEP-0115's
hash input format is one, but we generate that and don't parse it, and
XEP-0245 is pretty trivial.
However, I think that the benefits here outweigh the costs:
* The format is quite small, so a parser - while still a parser, with
all that that entails - is about as simple as one could imagine.
* The format is the same as plenty of other IM systems, so we know
it's proven useful.
That all said, I do not consider this a precedent for future XEPs to
specify a zillion different syntaxes. Our options for styling IM
messages are XHTML-IM, which has (in my experience and opinion) proven
a complex and dangerous thing to implement, this, or plaintext. I'm
happy to keep it at that. I'm not sure what other new syntaxes we're
likely to ever need.
More information about the Standards