On Thu, May 7, 2009 at 2:42 PM, Sam Johnston <samj@samj.net> wrote:
Ben,
An unimplementable specification is as useless as teats on a bull... I do think it's important that we bear the developers in mind where possible as if it's easy to develop for it's more likely to be used extensively.
I agree, yet don't understand how it applies to anything I've said. Are you really suggesting that using JSON would result in a specification that is "unimplementable"?
I'm going to assume you know what atom looks like up close and personal as I'm confined to an iPhone for now so my demoing ability is limited... if we leave the content element well alone then it is no more complicated than any XML based domain specific language we would create, especially if we keep it flat and/or limit ourselves to what is possible in text and json.
Further, these alternative transforms need be nothing more than convenience formats for writing shell scripts and web interfaces...
And we end up right back in the space I described in an earlier email: either we force all implementations to implement all formats or we guarantee the production of incompatible, fully compliant implementations. Riding the fence just produces a sore bottom. Make a choice.
and by providing ready made transforms they need be no more work for implementors. If an implementor wants to render direct to PDF for reporting then so be it. If they choose not to provide this extra functionality then let the market decide. So long as we focus on one primary format we're fine.
Sam
"If we don't do all the complex stuff for which XML-based systems are notorious, we'll be fine". There is a first time for everything. I'm not going to hold my breath, though. Ben