Hello all
Regarding the recent comments:
> > > So perhaps both approaches have their use cases? I don't fundamentally
> > > object to either, but including multiple renderings in a
> > > multipart/alternative style all the time just for improved handing of
> > > *this* seems overkill.
> > >
> >
> > What about an approach that allows both?
> >
> > Say we create a new element <content type='...'/> that we send with the
> > message. If it's empty, it could be considered a hint regarding the format
> > of the message body. If it is non-empty, it contains an alternative, a
> > formatted version of the plain text message body.
>
> I think allowing alternate content renditions could be opening up a whole can
> of worms. We already have the body for plain text and XHTML-IM for rich text.
> If the plain text version happens to be structured then I think hinting as to
> the underlying format is useful (and I am definitely emphasising that it?s a
> hint to make the point that it can be safely ignored).
It's an overly pessimistic view on things. It's a simple IF, to decide where to
take the information from, if you understand the content type. From the body
(if the element is empty) or from the element itself (if not).
>
> Some kind of type hinting solves the issue that sparked this thread, and I
> like the fact that it?s potentially not limited to markdown - you could
> imagine a system sending data in a yaml format for example, which is both
> human and machine readable. It?s also nice and simple.
No it does not. Since I sparked the thread I encourage you to read my comments
in the beginning.
> > What about an approach that allows both?
> >
> > Say we create a new element <content type='...'/> that we send with the
> > message. If it's empty, it could be considered a hint regarding the format
> > of the message body. If it is non-empty, it contains an alternative, a
> > formatted version of the plain text message body.
>
> it's ugly and messy in my opinion. We already have 2 syntaxes: text for
> client
> we can't or don't want to display rich content (e.g. console client), and
> XHTML-IM for rich content.
Then don't. I don't propose doing this as mandatory for clients to support. The
question is, IF clients want to send markdown, should it be done in a
proprietary fashion, or should the XSF provide an interoperable means to do
this? The XSF cannot block people from doing it, it can just choose to limit
interoperability, in case people want to, or help interoperability, by
providing a standardized means for how it should be done, if done at all.
>
> If we start to use rich syntax for text content, which syntax should I use in
> my client when both markdown and XHTML is there ? And what if clients start
> to
> send markdown only messages ? And what about the flavours ?
I guess that is a question for other forums, for instance once dedicated to
markdown.
> Markdown translates easily to XHTML(-IM) and the opposite works quite well
> too.
No, it doesn't actually. Generating HTML from markdown is easy, but not
markdown from HTML (or even knowing when received HTML is made from markdown at
all and can be converted).
>
> I think adding new syntaxes (non XML in addition, meaning that client need a
> specific parser) is a bad path.
Only if they want to support this new syntax. If users want a markdown syntax
in the chat client, then they would have to add a markdown parser, regardless
if it's sent or not over XMPP. If users don't want to use markdown syntax,
there's no need to worry. The only reason when you don't need to add a markdown
parser, is if you create a bot sending markdown messages from code. But if you
want to allow users to use markdown, you need a parser. If you don't want to
allow users to use markdown, you're not forced to.
Best regards,
Peter Waher
_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
