[phpsoa] Re: Time for DUNLIN to peck its way out?
I had a look at all these today. The nub of the problem is that both #11012 and #11004 point at JIRA #1297. I created the confusion in the first place when I raised Tuscany JIRA 1297 - I raised the original JIRA with a title that presupposed what the problem was. Really the problem is that the WSDL will not validate with visual studio, soapscope, oXygen, or, I now discover, XERCES. There appear to be at least two problems: xsi:type upsets visual studio the order of the http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Time for DUNLIN to peck its way out?
Hi Caroline, Thanks for the clarification. As I see it TUSCANY-1297 should be assigned to #11012. #11004 is an issue that I feel I was able to solve by hacking the SCA WSDL generator code. I think Matthew may disagree with my raised issue (looking forward to his response), but it is entirely solvable in the PHP code. Best, Mike > -Original Message- > From: phpsoa@googlegroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of Caroline Maynard > Sent: June 11, 2007 12:15 PM > To: phpsoa@googlegroups.com > Subject: [phpsoa] Re: Time for DUNLIN to peck its way out? > > > Michael Caplan wrote: > > > > I'd like to petition to get Bug #11004 (WSDL Generated Does Not > > Validate) and Request #10994 (Business Exceptions Data Returned to > > Client) in this release. > > > > Judging from [EMAIL PROTECTED] (sorry not sure who > that is) final comment on > > #11004, I think this ticket is being confused with Request #11012 > > (Visual Studio Consumption of SCA Generated WSDL) as suggested by the > > referenced by the Tuscany ticket. I believe #11012 should have the > > Tuscany ticket associated. If #11004 is being confused, I'd like to > > raise it hear again. The gist of #11004 is WSDL validation, and if I > > am correct about this, the fix seems to be simple, and outlined in > the > > ticket. > > It was me, but only from the point of view of getting that bug > processed > according to our standard procedure for handing off bugs to Tuscany. > Matthew had already raised it as a Tuscany JIRA, and my "contribution" > was to update his link from 11004 to the Tuscany defect with one that > would be clickable from within the PECL bug tracker. > > The Tuscany issue: http://issues.apache.org/jira/browse/TUSCANY-1297 is > indeed the one about suppressing the xsi:type attribute, so I see what > you mean. But I'm not sure whether the other one is also in Tuscany or > in Matthew's WSDL generation code. I'll hope that he responds ... > > > E-mail messages may contain viruses, worms, or other malicious code. By > reading the message and opening any attachments, the recipient accepts full > responsibility for taking protective action against such code. Henry Schein > is not liable for any loss or damage arising from this message. The information in this email is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this e-mail by anyone else is unauthorized. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Time for DUNLIN to peck its way out?
Michael Caplan wrote: > > I'd like to petition to get Bug #11004 (WSDL Generated Does Not > Validate) and Request #10994 (Business Exceptions Data Returned to > Client) in this release. > > Judging from [EMAIL PROTECTED] (sorry not sure who that is) final comment on > #11004, I think this ticket is being confused with Request #11012 > (Visual Studio Consumption of SCA Generated WSDL) as suggested by the > referenced by the Tuscany ticket. I believe #11012 should have the > Tuscany ticket associated. If #11004 is being confused, I'd like to > raise it hear again. The gist of #11004 is WSDL validation, and if I > am correct about this, the fix seems to be simple, and outlined in the > ticket. It was me, but only from the point of view of getting that bug processed according to our standard procedure for handing off bugs to Tuscany. Matthew had already raised it as a Tuscany JIRA, and my "contribution" was to update his link from 11004 to the Tuscany defect with one that would be clickable from within the PECL bug tracker. The Tuscany issue: http://issues.apache.org/jira/browse/TUSCANY-1297 is indeed the one about suppressing the xsi:type attribute, so I see what you mean. But I'm not sure whether the other one is also in Tuscany or in Matthew's WSDL generation code. I'll hope that he responds ... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Time for DUNLIN to peck its way out?
I'm happy to take a look at #11004 (everyone else has had a go so it's probably my turn :-). I see the difference between this and #11012 (I remember the xsi:type stuff coming up ages ago in Tuscany SDO as something that was required to get the C++ SCA implentation going - if I come across any info I'll see if we can fix that too). Regards Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: rest resource binding?
I referred to two approaches because I felt that the two 'interfaces' might not be progressive (i.e. steps down the same road). I suppose in some abstract way I could be wrong in that the path info in the URIs is an 'identity' in both cases (e.g. http:///Collection.php/12 versus http:///Collection.php/part/5/subpart/15). If the first case the identity passed to a retrieve, say, could be 12 and in the second it could be part/5/subpart/15. +1 for doing the simple CRUDE first :-) On 11 Jun, 11:01, [EMAIL PROTECTED] wrote: > I agree with Matthew's sentiment. I think we have enough ideas here to > have a crack at the simple CRUDE case. I view the second case as being > similar to the first case but with more complex URIs. I think it is > useful to point out that this extra complexity is required in reall > applications (which Joes presentation that Graham references makes > clear) but I think it's something we should consider as an extension > to the simple case. > > Regards > > Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Time for DUNLIN to peck its way out?
Hi Folks, I'd like to petition to get Bug #11004 (WSDL Generated Does Not Validate) and Request #10994 (Business Exceptions Data Returned to Client) in this release. Judging from [EMAIL PROTECTED] (sorry not sure who that is) final comment on #11004, I think this ticket is being confused with Request #11012 (Visual Studio Consumption of SCA Generated WSDL) as suggested by the referenced by the Tuscany ticket. I believe #11012 should have the Tuscany ticket associated. If #11004 is being confused, I'd like to raise it hear again. The gist of #11004 is WSDL validation, and if I am correct about this, the fix seems to be simple, and outlined in the ticket. As for #10994, it appears that consensus has been reached on suppressing the backtrace. I've included a code snippet for evaluation in the ticket that could be applied to the SOAP wrapper (and easily adapted to the other bindings). best, Mike On Jun 11, 7:05 am, [EMAIL PROTECTED] wrote: > No, sounds like a good idea. I still have some binding documentation > that I want to write but that won't be shipped with the release. Are > there any of bug fixes that we need to get in. > > Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: Time for DUNLIN to peck its way out?
No, sounds like a good idea. I still have some binding documentation that I want to write but that won't be shipped with the release. Are there any of bug fixes that we need to get in. Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: rest resource binding?
I agree with Matthew's sentiment. I think we have enough ideas here to have a crack at the simple CRUDE case. I view the second case as being similar to the first case but with more complex URIs. I think it is useful to point out that this extra complexity is required in reall applications (which Joes presentation that Graham references makes clear) but I think it's something we should consider as an extension to the simple case. Regards Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Time for DUNLIN to peck its way out?
We seem to have done the things that we said we would do in http://groups.google.com/group/phpsoa/web/content-of-release-from-dunlin-branch so I propose to package it up into a release later this week - Wednesday afternoon, say. Any objections, anyone? It'll then be time for EAGLE or EIDER. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: rest resource binding?
I like the idea of walking one step at a time towards the goal, so that we do the simple case well at first. You say "two approaches", I hope they are really one approach, but one more elaborated than the other, so two steps down the same road, not one step each down two separate roads. That's never comfortable :-) On Jun 11, 8:59 am, Graham Charters <[EMAIL PROTECTED]> wrote: > I was thinking about this a little over the weekend. I wonder if we > should have two approaches: > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
[phpsoa] Re: rest resource binding?
I was thinking about this a little over the weekend. I wonder if we should have two approaches: 1. There appears to be a common pattern for simple resource REST services where you just have CRUDE operations and there's a single collection (the collection has a URI and so do each of the items in the collection). This is how RSS, Atom, and simple REST and simple database scenarios work. 2. There is then the more complicated world where the URIs specify resources which are perhaps more complex queries or are resource joins (e.g I want the contact and address details for people in New York state). Not sure how you'd express that :-o http://./Contacts.php/contact/address?state=New%20York . Perhaps for this world we just provide a CRUD interface and then it's up to the implementor to interpret the URIs. Doesn't feel particularly helpful, but we might then spot patterns for other REST styles which can then be encapsulated in new bindings or helper functions. Graham. On 7 Jun, 17:42, Graham Charters <[EMAIL PROTECTED]> wrote: > On 7 Jun, 16:10, Matthew Peters <[EMAIL PROTECTED]> > wrote: > > > I'm glad you like the idea, and you ask a good question. It has always > > seemed to me that right at the bottom we have service-oriented > > components and resource-oriented components, and that the service > > oriented ones can all be totally different but that at one level the > > resource-oriented ones are all the same - there should be a CRUD > > component at the top/bottom from which they all inherit, and > > rest.resource inherit from that. What useful shared logic it could > > have I don't know - perhaps it is just an interface i.e. method > > signatures and constants. > > I mostly agree with this, and for basic resource-oriented services > CRUD (should probably be CRUDE because we typically need an Enumerate > (aka list) capability) would suffice. Atompub is a good example > here. Also, a basic REST CRUDE could be used to provide simple REST > access to databases. > > However, I think in many REST scenarios, there are more capabilities > we need to support. I find the REST presentation by Joe Gregorio > (seehttp://bitworking.org/projects/rest/) very enlightening. The example > he shows at the end (slide 50http://bitworking.org/projects/rest/50.html) > has quite an elaborate set of URIs the likes of which we will probably > need to be able to support. The resource in this example is Accounts > for a review service. It would be good to start with an example like > this and see how it would map down to an SCA component with a REST > binding. I think chances are we will end up with more methods than > CRUDE. > > Regards, Graham. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~--~~~~--~~--~--~---
