EchoStandards
now see Atom Standards
WebLog-related Open Standards activity initiated (2003-06-24-RubyWeblogStandards) by Sam Ruby.
Discussion via Wiki For CollaborationWare.
RemoteWikiURL:http://intertwingly.net/wiki/pie/
Also lots of postings to Sam Ruby's blog.
summaries at http://danja.typepad.com/fecho/
Encompasses adjustment/replacement of:
-
RSS with Echo Standards:EchoFeed
-
MetaWeblog API with Echo Standards:EdingApi
I'm not clear why they couldn't make incremental fixes to these and rewrite the spec to clear up any current ambiguities. If they think Dave Winer will be in the way, they could just basically pick new variant names, make it clear they're "taking over the process" from him to make it vendor-neutral. This reminds me of Cory Doctorow's Whuffie process.
-
Rogers Cadenhead has started a list to disambiguate the RSS v2 spec.
-
Mark Nottingham wrote (Apr18'03) a version of the RSS v2 spec to submit to the IETF. I have no idea how he handled the ambiguities. He now supports the Echo Standards group.
I fear this will eventually recapitulate the RDF/nonRDF battle.
-
No, looks like that's been put aside. Echo Standards:RdfAndEcho - What we can expect, though, is for people familiar with RDF to help make sure things that would make interoperability with RDF better, simpler, or easier, to speak up about it - RDF applications will be among the users of Echo.
-
on the other hand, it is going through the XmlRpc vs SOAP vs ReST thang.
Some people, particularly those of the UserLand community, think there are some potentially very-bad outcomes of this process. What could happen? (There are plenty of arguments against any of these things happening, but I wanted to get some specific scenarios down. I'll let others take it from there, I'm not close enough to keep up.)
-
The Echo Standards become overly complex (if not in v1, then maybe in v2 when "the community" gets more skewed toward IBM (Sam Ruby's employer) and Microsoft and AOL. (Some would argue that many standards are intentionally made too-complex to raise the cost of complying, freezing out the experimental developer. Analogy: do you think that "license" requirements for hairdressers are there to "protect consumers" or reduce the entry of new competitors?)
-
Microsoft, making both WebLog authoring tools and RssAggregator-s, supports the complex Echo Standards but not the simpler older standards, even if they would be sufficient. (MsExchange/MAPI vs IMAP, ICal; MsOffice file formats)
-
Or maybe they use the existence and ongoing discussions of Echo as a FUD argument for "those small guys don't know what they're doing, we'll make our own closed formats".
-
AOL does the same thing - 2003-07-04-AolBlogs
-
Google/Blogger does the same thing: 2003-06-25-GoogleToolbarBlogger, Echo Standards:BloggerProposals
-
the Echo Standards process becomes more of a pain in the ass over time. Either a "needed" change takes forever because of a committee (and physical meeting) process (time and money barrier), or pointless changes get added constantly and conservative customers eat FUD about InterOp, so they stick with the big guys. The small guys get tired of worry about the old standards when the new ones are keeping them so busy, so they drop the old standards.
-
people with new ideas about interface/model realize they can't put out an alpha without supporting Echo Standards, but the specs have gotten so big (e.g. XML) that they get pissed off and drop the idea, because the fun has been sucked out...
-
etc.
Edited: | Tweet this! | Search Twitter for discussion