Tim Bray <tb...@textuality.com> writes:
> There's a disconnect here. Mnot and I (at least) have argued that
> there are very specific problems and costs associated with going
> multi-format. I’ve heard lots of people say "Well, I support
> multi-format” but I haven’t heard any specific responses explaining
> why those costs and problems aren’t real, or why the benefits are
> sufficiently great that we should just accept them.
>
> Mnot: JSON or XML: Just Decide
> http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide
> tbray: Case Study: Atom and/or JSON
> http://www.tbray.org/ongoing/When/200x/2009/04/29/Model-and-Syntax#p-1
>
> Would this work better if I summarized the problems here inline in
> this thread? It may be the pace that people’s IETF/email workflow is
> such that they’re not able comfortably to consult external references?
No, but I disagree with your conclusions. Indeed, I disagree with your
problem statement. Just because the server supports multiple formats
does NOT imply more work for the client. The client can request a
specific format and never has to worry about the other, so it has NOT
doubled the work on the other side.
Let's take your rails example. Yes, it's simple for a rails server to
output HTML, XML, JSON, and other formats. But no, this does NOT make
it harder for the consumer of that content. The consumer can
specifically ask for whatever format it wants! This means you can have
a JSON-only client and it can interact 100% with your rails application
using just JSON. It doesn't have to worry about receiving XML, because
it will always get JSON.
As for your abstract model issue.. Maybe Mike was right and we SHOULD
use ASN.1! :-D Then we could have defined encodings to XML or JSON ;)
> -Tim
-derek
--
Derek Atkins 617-623-3745
de...@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
