If you'd like to escalate this to a full discussion, that's fine. Sadly, I think you've misread my arguments quite thoroughly, assuming that I was arguing about REST/RPC issues.
In fact I'm saying that your proposition of imposing SOAP Envelope elements into the definition of what an item may contain is just as distasteful as the assumption that xsi:type attributes can be scattered through a document with no ill effect on software.
Requesting that "two tags be permitted and ignored" raises some serious questions when those tags are containers - as I believe SOAP elements are intended.
There is NO defined processing model for such cases - does "ignore" mean "ignore the tags" or "ignore the element"?
That makes a huge difference on what you do with the content, and it's awfully hard to talk about ignoring tags if, for instance, you live in the world of the XML Infoset (as SOAP quite explicitly does), which has Element Information Items, not start and end tags:
It's nice for all of us to assume that our projects are practical and concrete. It's nice to assume that the seeds we want to plant will grow into lovely ornamentals. Unfortunately, some of those ornamentals are kudzu, and Stop Energy is sometimes necessary:
I've been watching this particular thread with interest. Nothing to interject into the original discussion (not in this august company), but a little to interject with this specific posting.
Seems to me when there's confusion about implementation and intent, and concerns about same expressed, that's when you want to talk and _not_ act. When you reference the 'Bias to Action' concept from Apache, isn't this the same as saying "I like this. I'm going to build it. Unless you're faster than me, I'll be first, and you'll have to live with it."
Seems to me that this shuts down a pretty viable conversation, extending to several different intersts. Kind of a stop energy feel to it. No offense.
But then, I haven't irritated anyone today, and it's evening and I am running out of time...
(Now, we just need to implement the _____ application that can track these conversations across web site, weblog, XML-Dev discussion group, and Yahoo groups as well.)
I'll respectfully disagree with you Shelly. Right now the technology is still pretty new and I would prefer to see multiple competing implementations. And that means RESTLog, it's XML formats, RSD, and Trackback for starters. This gets back to my reasons for starting WellFormedWeb.org, I learn best by doing and some things only become evident once you try to do them. An implementation isn't the end of a discussion, but something to have a discussion around.
There is something to be said for a working implementation of an idea. Even the W3C now has rules in place that a spec can only move to recommendation if it has two independent implementations.
That's okay, Joe. You can disrespectfully disagree with me, as long as you spell my name right ;-)
Not a problem with everyone trying out new things. We all do that here all the time, as witness Ben Trott's recent track-rdf-back tool he created for Ben H. That's great.
But I think that's different than what Sam described in Bias to Action (implementation, which is then patched). Even within the W3C, there's a concensus about the general format of the specification, first, before people run off to implement it.
Again, seems to me that there's some basic disagreement with the premise, much less implementation. A little time for talking, perhaps exposure in different venues might lessen some of those patches. And also might introduce new ideas.
Still, nothing to stop people from sitting down and coding right now, and pushing it out as fait acompli (did someone mention RSD?) Shuts the people who aren't fast coders out of the conversation, but tech is Darwinism at its best -- only the fit survive.
"But I think that's different than what Sam described in Bias to Action (implementation, which is then patched). Even within the W3C, there's a concensus about the general format of the specification, first, before people run off to implement it."
In the particular case of what Sam's proposing, I think a dose of "Stop Energy" now might spare a lot of cycles later. I don't think including "ignorable" SOAP element containers should have any direct impact on this project, and it's probably something better done as a patch later IF FOUND ABSOLUTELY NECESSARY than at the outset.
That's all we have here, plus a little amusement with people who think shouting "Stop Energy!" should end any questions immediately.
On GET and DELETE, I don't really have an answer for you, Joe.
On this bit: "I agree with Simon that the use of envelopes is a long term problem. For example what if XForms required it's own wrapper around the instance data? (It doesn't) Then I would have to serve up three forms of an 'item', one plain, one wrapped in a SOAP envelope, and another wrapped in an XForms envelope."
That kind of infinite envelope variety problem is a lot of what bothers me here. I don't think any schema language to date (maybe Schematron?) lets you say that "A can hold any type of element, provided that those elements contain more of A" or somesuch. Interesting problem, but a real one.
Container elements are very cool things, but they aren't exactly interchangeable. I'd avoid adding extras at this point.
Simon, I have to agree with Sam here that you seem interested in primarily providing STOP ENERGY instead of concrete complaints. The problems you raise about either processing or ignoring elements from a particular namespace seem more tied to how you typically write code (i.e. processing via SAX) than on whether ignoring or accepting element information items from different namespaces is acceptable or not.
I read your post on XML-DEV and have posted a reply. I'd be very interested in reading what you have to say.
On bias for action: <br/><br/> One of the nice side-effects of software is its adaptability: it can (and will) be rewritten. They even coined the term refactoring for that. Now if someone comes up with a premature implementation, this has infinite more value than coming up with nothing more than a belated spec. Recent W3C recommendations are archetypes of community specs without the community design/implementation to prove them.
Shelley said: "Shuts the people who aren't fast coders out of the conversation, but tech is Darwinism at its best -- only the fit survive."
Nah. By keeping it simple we keep coding prowess from being a factor and keep FUD to a minimum.
I once had a programmer who worked for me who seemed to always choose the most obscure way to write code. Then I saw a comment in his code that said "job security." I asked him what it meant and he told me that he always coded stuff the more complex way if possible, so that he couldn't be fired. Needless to say he quit eventually (he was right, I couldn't fire him) and we cursed his name from then on whenever we had to work on some of his code. It was so fragile anytime you as much as looked at it it would break.
God Simon, I bet you don't even understand the problem. In any case, the train left the station approx three years ago when we released the ManilaRPC interface. Newbies, gotta love em. They think they rule the world. Heh.
Dare, I saw your answer to Simon at XML-Dev. I hope you don't mind me responding here. Friendlier environment.
I once had to figure out how to modify a large C application that was used to map the geography of the Firing Center in Yakima, Wa. There was no documentation, internally or externally. The professor connected me with the original developer to review the architecture of the application. When I met him, he spent exactly 15 minutes writing out some C code on the back of a napkin.
"That's all you need", he said, handing me the napkin with a flourish.
A long way of saying that it seemed to me that Simon was addressing possible problems of future interpretation using a specific example; not necessarily asking for coding how-tos. Sometimes code isn't always the answer.
And he was trying to provide a specific example of his concern. Not sure where 'stop energy' is coming into this.
Steve, I worked with a crippled OLE then COM implementation for years before it started, slowly but surely, being strengthed (albeit not perfectly) into COM+. And we still have old ISM databases we can't seem to rid the world of.
For a new example, the RDF working group has had the worst time with the original concept of containers and reification because the original design was flawed, but hurridly added to complete the spec. Now there's implementations of this all over, and their hands are tied because of their charter (and they've been given a lot of s**t because of this).
There is a difference between putting out utilities and applications, or new uses of existing specifications (such as RSD) and making what could be too quick modifications to an underlying specification. Modificatinos that could impact on its overall usability in the future. (Why does the Blogger API come to mind right about now?)
It is incredibly difficult to get rid functionality based on 'bad design' once it hits the mainstream.
Dave, I would hope that we're keeping it simple -- but there is an element of 's/he who gets there first with code, wins' to much of this activity. Also a bit of the old "code first, design later" to all of our rush to get _something_ out as quickly as possible.
You know me, ole Shelley 'stop energy' Powers, hollerin' out "What's the bloody rush?"
An, Shell -E- y I should say.
And I don't see Simon as a newbie because he's raising concerns (at least that's my interpretation of your second comment -- could be wrong). Simon has good points. I may not agree with all he says, but he deserves hearing. Seems to me he understands the problems just fine. Just that people want to code, not talk.
Fine, as long as we're all willing to live with the results.
Sorry, IMS. Also sorry, Sam -- just realized who remembered who produced IMS. Also, I realize that relational isn't the model for all purposes and a hierarchical model is more appropriate for some uses. Urh. Didnt mean to come in as a relational data bigot. Urh.
Hmm. Not sure, Sam, what that comment has to do with this discussion. My RDF apps really have no tie-in here, other than Aaron did have a post w-a-a-a-y back that if folks used an underlying meta-model with XML, we wouldn't continue having these issues.
My concern is that I'm being told to either 'put code up' or drop out of the discussion. Is this a Coders only Club? Well, at least its different from men or white's only, and does form an interesting acronym -- COC.
However, I'm usually wrong on interpreting these things Monday morning.