On Montag, 1. Juni 2020 15:28:40 CEST Maxime Buquet wrote: > On 2020/06/01, Jonas Schäfer wrote: > > [..] > > > > First off, as Dave mentioned already (and as "everyone" will already > > know), > > arguably this is deployed very widely. And not because of '393, > > specifically, but because people have been using these types of > > metamarkers for so long already that nobody could possibly trace it down > > to a single source. In a way, they are similar to quotation marks; > > they’ve become part of an additional grammar used by many people > > throughout the internet. > > > > There are "cultural dialects" (e.g. the various markdown flavors), but > > there is basic compatibility. Pinning down the XMPP dialect of this is a > > good` thing™. > > I disagree. I think this is a bad idea and that we shouldn't endorse > this as the XSF. XMPP is not a product line, it's a protocol. What > specific sigils are being used (as input format) shouldn't be enforced > at the protocol level.
I expect us to Deprecate / Obsolete the spec once we have a replacement with a proper wire format for conveying markup. If you feel strongly about this situation, the best way to fix it is to make a proposal which replaces the versatility of XHTML-IM (with some accessibility (colours) fixes). You’ll find lots of inspiration in the threads from the Eternal October 2017 where the Styling discussion first came up [1]. I expect this task to be about as fun as trying to get a Compliance Suite to Draft. Then we can Deprecate or Obsolete '393 and move the input format recommendations to a UX-centric location (either as "Implementation Note" in XHTML-IM-NG or a third-party resource). With the proposed additions, the document does indeed define a (albeit ugly) wire format to be used within XMPP. The <styling/> element clearly signals that a specific (albeit ugly) wire format (inside <body/>) for marking up text is used, which has a rather clearly defined effect. This is useful for non-IM and non-human-operated entities, too. > > However, we need a way forward which will not have to rely on transmitting > > these markers on the wire. And we also need to be able to deal with > > entities which send text which is strongly not intended to be formatted > > based on those markers. > > > > With the proposed mandatory opt-in and opt-out solution, we get both of > > that. I *hope* that clients which unambiguously support '393 will start > > to add the opt-in so that the default behaviour (in absence of any > > marker) can move back from "styled" to "unstyled". In addition, should we > > ever have to iterate on this document (either in a new XEP or in this > > thing while it’s in draft), we now have a wire format element of which > > the namespace can be bumped.> > > On Montag, 1. Juni 2020 10:23:37 CEST Dave Cridland wrote: > > > [..] > > > If we have a hint and (approximately) the text above in the > > > specification, > > > is this enough to make people... if not actually happy, at least willing > > > to > > > grudgingly accept the document? > > The proposed changes are indeed better than 393 as is for reasons jonas > mentioned. > > These changes de facto make the XEP an opt-out XEP though, as long as > the default is to interpret <body/> for markup. The default in *current* implementations of the (un-namespace-versioned) '393 is indeed. With the wording proposed by Dave, implementations "MAY" choose styling as default, but they don’t have to. Implementations can very well choose to offer this optionally and/or have unstyled by default if the coverage of the <styled/> tag is widespread enough. kind regards, Jonas [1]: Some links: - Original thread by Sam: https://mail.jabber.org/pipermail/standards/2017-October/033546.html - Rich text thread by Dave: https://mail.jabber.org/pipermail/standards/2017-October/033596.html - Formatting Use Cases thread by Sam: https://mail.jabber.org/pipermail/standards/2017-October/033702.html
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
