1. I confess: not a fan of the "coopetitor" neologism
2. if we're going to use it, I would much rather it not be a cardtype that overlaps with other cardtypes (like company). Seems like it should be integrated with CRM.  could we make coopetitor a tag or something?
3. as we have it defined now, coopetitors are projects; REST is a standard.  doesn't it seem different? 

I was trying to avoid an immediate multiplication of cardtypes for things we would or would like to draw from, make use of, and/or work with - there are software projects, specs/standards, web services, organizations, and maybe more. I get your dislike of coopetitor, so I'm going with the flow of your name change to Peer. One cardtype for now simplifies Wagneering. Totally open to an effort to beef up this part of wagn.org at some point.

  --John Abbe.....Tue Feb 22 11:11:29 -0800 2011

A case for inheritance in cardtypes? Then you could have different kinds of Peers that would share many things. One difference is that things like this have a good chance of becoming part of the implementation in the future.

Agree we'll want inheritance for cardtypes. Meanwhile, Ethan came up with a great workaround for form variations based on plus cards? In this case, I was/am trying to put off the (to me, premature) Wagneering work. E.g., I don't even want to think right now about what goes on the form of a specification vs. an organization.  --John

In particular REST will be used in the XML module. Or maybe better phrased this way: The XML module will implement a REST interface using the Wagn Action API

  --Gerry Gleason.....Tue Feb 22 12:50:32 -0800 2011