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 WSD
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 s
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
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 in
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:///C
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 Re
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 subscrib
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
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.
--~
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 nev
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
11 matches
Mail list logo
