> 1. Do nothing. The APP is limited to talking about how you > traverse, add entries to, and delete from, collections, > saying nothing about how you find them.
+2 I have been giving this a tremendous amount of thought, as we all have, and feel that our highest priority as a group should be to build concensus around a core protocol. I know the debate for many of us is the definition of "core," and for each of us we have a slightly different answer. But I challenge everyone to ask themselves, "what will help us build concensus and get something in the hands of the marketplace more quickly?" To that end, I think we can accomplish a great deal by de-coupling introspection from the *Core* Atom Publishing Protocol. Doing so would dramatically simplify APP, and IMHO, simplicity is the key to most successful and broadly adopted specs. Ok. Now. That being said, I believe strongly that what has been specified so far IRT introspection has a lot of validity and merit. I feel that when considered by itself we would be able to build concensus on an introspection standard more quickly than if we were to lump APP and Introspection together. Personally, I think there is a lot to be learned from the W3C and SOAP. I am not advocating us learning from the specifics of their specifications, not at all, but I am suggesting we take a lesson from how they segmented their specifications and process. By separating out the protocol from the description of an endpoint they kept SOAP incredibly simple (far simpler than Atom even) and were able to agree more quickly. Then a separate group focused on the use cases surrounding description and interface definition of those SOAP endpoints. And as a direct result, I believe they were able to come to an agreement more quickly on both specifications (SOAP and WSDL) than they would have if they tried to combine the two. I think we should take what lessons we can from the groups successful in creating standards roughly analogous to our own. So here is my proposal: 1) Have the core APP specification focus on how to inform a client where to find an introspection or description document, and let another group sort of the specifics of that document. I would innaugurate that group with a spec based upon what is in the latest draft. We are close, but I don't want to build a dependency into a simple protocol for creating, updating and deleting media and entries on how to describe the infinite ways to describe various idiosyncractic feature sets of Six Apart, Google, Word Press, Roller, and a million other services emerging in the marketplace. > 2. draft-protocol-06 approach: see > http://bitworking.org/projects/ > atom/draft-ietf-atompub-protocol-06.html#appdocs - a custom > XML vocabulary that describes collections and their capabilities. -1 See above. > > 3. PaceAppOutline - another custom XML vocabulary which > supports arbitrary nesting of collections, for which there > are a couple of plausible use cases. See > http://www.intertwingly.net/wiki/pie/ > PaceUseAppOutlines -1 See above. Plus I believe someone recommended a #4 which provided a <link rel="introspection"> mechanism of some kind. I think that is perfect. Let's enable ourselves to decouple these two dramatically different problems. Byrne Reese Manager, Platform Technologies Six Apart, Ltd. [EMAIL PROTECTED] PS. Because I don't think the chairs get enough recognition. Thank you so much for all your hard work. This is one of the most verbose lists I subscribe to, and I have a hell of a time keeping up with it all. You guys do a tremendous job, and Six Apart is in your debt. Thank you thank you thank you. +1 +1 +1.
