ATOMPUB binding

[Matthew Peters]

We have a first attempt at a ATOMPUB binding sitting on a server here
that has quite made it to the outside world. It was mostly written by
Megan Beynon - she put a lot of work in but then had to move to
another project.

The essential idea is that you can define a proxy for a remote
component that talks ATOMPUB - something like this:

/**
* A reference to the contact feed service.
*
* @reference
* @binding.atom http://localhost/examples/SCA/Atom/ContactFeed.php
*/
public $contact_feed;

Then you can call methods like create, retrieve, update, delete and
enumerate on the proxy, and it will talk ATOMPUB to the far end, where
there is a component that looks like this:

* @service
* @binding.atom
*/
class ContactFeed {
.../...

that contains create, retrieve methods, etc. Of course like the other
bindings that talk a well-known web protocol the idea is not just to
go SCA to SCA, but that a client using the proxy can consume and
publish to atom feeds that are produced by some other non-SCA
producer, and likewise the feed that an SCA component produces can be
consumed and published to by anything that talks ATOMPUB.

So, although it's not finished, it might as well be not finished
sitting in the outside world where people can see it, as sitting in
the dark on a server here inside IBM, so I propose to check it into
PECL on a development branch, and work occasionally on it there (I'll
make sure it does not get in to a release until it is a bit more
robust.) I'll put a known-problems-and-todo-list up on this google
group as a page also.

If anyone has an application where they would really like such a
thing, but does not mind if progress is a little slow, I'd be glad to
hear from them. Also, if anyone is excited by the idea of taking a
look at it and making it better I'd like to hear from them too!

Matthew


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters]

Shame I didn't read it through carefully before posting - that should
be
"that has *not* quite made it to the outside world ..."

Post by Matthew Peters
that has quite made it to the outside world. It was mostly written by

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[simonslaws-gM/Ye1E23mwN+]

Post by Matthew Peters
Shame I didn't read it through carefully before posting - that should
be
"that has *not* quite made it to the outside world ..."

Post by Matthew Peters
that has quite made it to the outside world. It was mostly written by

+1 checking it into PECL cvs sounds like a good idea to me.

Simon


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Graham Charters]

+1 from me too :-) . I'd like to progress this, and pecl seems like
the best place to do that.

Post by simonslaws-gM/Ye1E23mwN+

Post by Matthew Peters
Shame I didn't read it through carefully before posting - that should
be
"that has *not* quite made it to the outside world ..."

Post by Matthew Peters
that has quite made it to the outside world. It was mostly written by

+1 checking it into PECL cvs sounds like a good idea to me.
Simon

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters]

I ave check it into EIDER, along with its phpunit tests and example (a
good starting point is examples/SCA/atom/test_contact_feed.php). I
have also put up some rather cryptic notes at
http://groups.google.com/group/phpsoa/web/todo-list-for-the-atom-binding
- these are what I gathered when talking to Megan about it (she wrote
it in the first place).


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters]

"I ave check" - what has happened to me :-) Mental note - read the
post through before clicking on Send.

Post by Matthew Peters
I ave check it into EIDER, along with its phpunit tests and example (a
good starting point is examples/SCA/atom/test_contact_feed.php). I
have also put up some rather cryptic notes athttp://groups.google.com/group/phpsoa/web/todo-list-for-the-atom-binding
it in the first place).

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Caroline Maynard]

Post by Matthew Peters
If anyone has an application where they would really like such a
thing, but does not mind if progress is a little slow, I'd be glad to
hear from them. Also, if anyone is excited by the idea of taking a
look at it and making it better I'd like to hear from them too!

I had a go with the Atom binding a few days ago, to try to implement a
quick solution to a challenge from a colleague - results may appear as
an article sometime in the future. I'm sorry to say I gave up after a
while and instead provided a solution using CURL and XMLWriter :-(

The nature of the problem was to create a new feed entry with specified
content, in a particular format, using Atom. So I needed, in my SCA
client, to create the xml for the entry, and POST it to the non-SCA server.

I do realise that the Atom binding is experimental, and indeed that some
of the problems may be my mistakes - here follows a list of the issues I
encountered.

1. The examples led me astray
Like all lazy programmers, I started out trying to hack the example
code. This told me that it was not possible to use SCA:getService() with
Atom services. For example, ContactFeedConsumer starts out:
/**
* A component which consumes a contact atom feed service. This is
* currently required because of the lack of support for
* SCA::getService() for atom services.

and continues:
/**
* A reference to the contact feed service. The Atom xsd is currently
* required to be specified, but my abe optional in the future.
*
* @reference
* @binding.atom http://localhost/examples/SCA/Atom/ContactFeed.php
* @types http://www.w3.org/2005/Atom Atom1.0.xsd
*/

Now, I later learnt that getService >does< work, if I specify the
binding type as the second parameter, but I didn't know that at first,
so tried to create a local service similar to ContactFeedConsumer. The
problem was that I couldn't find a way to specify a path to the
Atom1.0.xsd file in the SCA/Bindings/atom directory, and ended up having
to copy it into my client directory. Apparently the @types is no longer
necessary either. Good news, but without updating the examples, other
people are likely to be confused, too.

2. The Atom Proxy didn't honour http 301 status code
I assumed this was an oversight, since other SCA proxies which make use
of cURL do have CURLOPT_FOLLOWLOCATION, so I updated the code, after
discussion with Graham. However I did subsequently (I know!) read the
relevant RFC which suggested that the automated redirect should only be
used for GETs. So if the omission was deliberate, I apologise.

3.The Atom Proxy doesn't support common HTTP headers
No surprises here, this is a known problem common to all the SCA proxies
which use cURL. For the server I was using, I needed to add
CURLOPT_HTTPAUTH => CURLAUTH_BASIC
CURLOPT_USERPWD => "$user:$passwd"
CURLOPT_SSL_VERIFYPEER => false
(though I should have used a more secure solution to the last of those).
We've talked before about needing some sort of configuration side file
to let SCA work in the real web world. I hacked my local copy to get
round this for now.

4.The Atom Proxy ended catastrophically on failure
I managed to break the proxy in various ways, with PHP Fatal errors
resulting from failed requests where the failure conditions were not
guarded. The two significant omissions were not checking that the result
was not null before passing it to _fromXML(), and not checking the
cURL errno before attempting to process the status code and the result,
which were uninitialised. It would be nice if these conditions were
returned as exceptions.

5.Server rejected the generated XML
I use the following code to generate my feed entry:

$xmldas = SDO_DAS_XML::create("Atom1.0.xsd");
$document = $xmldas->createDocument(
"http://www.w3.org/2005/Atom", 'entry');
$entry = $document->getRootDataObject();

/* Fill in the entry here */

return $xmldas->saveString($document);

and got xml data looking like this:

<?xml version="1.0" encoding="UTF-8"?>
<tns:entry
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:tns="http://www.w3.org/2005/Atom">
<author>
<name>Caroline Maynard</name>
</author>
...
</tns:entry>

the server barfed on this, with status code 400 and message "Unable to
parse atom post entry". No doubt someone who knows namespaces better
than I do will correct me, but isn't that wrong, because <author> and so
on belong to the Atom namespace?

Anyway, even if technically correct, this particular server didn't like
it. A hand-cranked version:

<?xml version="1.0" encoding="UTF-8"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<author>
<name>Caroline Maynard</name>
</author>
... identical content here
</entry>

was consumed OK at the server.

Sorry that went on a bit. Comments?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Caroline Maynard]

Post by Caroline Maynard
5.Server rejected the generated XML
$xmldas = SDO_DAS_XML::create("Atom1.0.xsd");
$document = $xmldas->createDocument(
"http://www.w3.org/2005/Atom", 'entry');
$entry = $document->getRootDataObject();
/* Fill in the entry here */
return $xmldas->saveString($document);
<?xml version="1.0" encoding="UTF-8"?>
<tns:entry
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:tns="http://www.w3.org/2005/Atom">
<author>
<name>Caroline Maynard</name>
</author>
...
</tns:entry>
the server barfed on this, with status code 400 and message "Unable to
parse atom post entry". No doubt someone who knows namespaces better
than I do will correct me, but isn't that wrong, because <author> and so
on belong to the Atom namespace?
Anyway, even if technically correct, this particular server didn't like
<?xml version="1.0" encoding="UTF-8"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<author>
<name>Caroline Maynard</name>
</author>
... identical content here
</entry>
was consumed OK at the server.

Do you think this is likely to be fall-out from the fix for
http://issues.apache.org/jira/browse/TUSCANY-1112 ?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Caroline Maynard]

Post by Caroline Maynard
For the server I was using, I needed to add
CURLOPT_HTTPAUTH => CURLAUTH_BASIC
CURLOPT_USERPWD => "$user:$passwd"
CURLOPT_SSL_VERIFYPEER => false
(though I should have used a more secure solution to the last of those).

For the record, I did subsequently demonstrate that I could make this
work by removing the setting above which turns off SSL_VERIFYPEER, and
instead setting :
CURLOPT_CAINFO => /path/to/my/cacert.pem

so that it checked the certificate rather than ignoring it.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Graham Charters]

Hi Caroline,

Thanks for your feedback on your experiences with the Atom binding.
Doesn't make good reading, but it's very helpful. I'm not able to
work on this for the next couple of weeks, but hope to get time to
work on SCA the week after. Atom was going to be one of the things I
wanted to look at :-) .


Graham.

Post by Caroline Maynard

Post by Caroline Maynard
For the server I was using, I needed to add
CURLOPT_HTTPAUTH => CURLAUTH_BASIC
CURLOPT_USERPWD => "$user:$passwd"
CURLOPT_SSL_VERIFYPEER => false
(though I should have used a more secure solution to the last of those).

For the record, I did subsequently demonstrate that I could make this
work by removing the setting above which turns off SSL_VERIFYPEER, and
CURLOPT_CAINFO => /path/to/my/cacert.pem
so that it checked the certificate rather than ignoring it.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters]

Caroline,
I've been looking at problem 5 in your list here - the server
rejecting the generated XML. I think our Atom1.0.xsd is wrong.

Our xsd has no elementFormDefault attribute on the schema definition.
This means that we get the default behaviour, which is that only top
level elements defined in the schema are in the target namespace, and
elements that are not defined at the top level e.g. <author> and
<name> and so on are in the no-namespace namespace.

Consequently the XML we generate has lower level elements like author
and name not in any namespace, which is correct according to the
schema that we have.

I am tempted to add elementFormDefault="qualified" as an attribute to
the schema element, putting all the lower level elements into the atom
namespace. I have checked this out with XERCES, which I take to be the
authority in this matter - with the xsd as we have it the hand-cranked
xml fails to validate but add the elementFormDefault attribute to the
schema and it passes.

This did all change around the time of jira 1112 - the xml we were
generating was all wrong before and the elementFormDefault attribute
was being ignored but it should be behaving according to spec now.

Incidentally, could you paste in a little of the code that used to add
the fields to the entry? I am finding it very hard to write the code
that creates an entry - something to do with the weird many-valued
nature of entry and author....

Matthew


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Caroline Maynard]

Post by Matthew Peters
I've been looking at problem 5 in your list here - the server
rejecting the generated XML. I think our Atom1.0.xsd is wrong.
Our xsd has no elementFormDefault attribute on the schema definition.
This means that we get the default behaviour, which is that only top
level elements defined in the schema are in the target namespace, and
elements that are not defined at the top level e.g. <author> and
<name> and so on are in the no-namespace namespace.
Consequently the XML we generate has lower level elements like author
and name not in any namespace, which is correct according to the
schema that we have.
I am tempted to add elementFormDefault="qualified" as an attribute to
the schema element, putting all the lower level elements into the atom
namespace. I have checked this out with XERCES, which I take to be the
authority in this matter - with the xsd as we have it the hand-cranked
xml fails to validate but add the elementFormDefault attribute to the
schema and it passes.
This did all change around the time of jira 1112 - the xml we were
generating was all wrong before and the elementFormDefault attribute
was being ignored but it should be behaving according to spec now.

Your analysis makes sense - I experimented with changing the schema as
you suggest, and the following popped out:

<?xml version="1.0" encoding="UTF-8"?>
<tns:entry xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:tns="http://www.w3.org/2005/Atom">
<tns:author>
<name>Caroline Maynard</name>
</tns:author>
<tns:title>
...
</tns:title>
<more stuff here/>
</tns:entry>

which probably is technically correct, as it now has the author in the
atom namespace. However the problem for me is that this particular
server still doesn't like it - it gives me a response code 400, but
instead of the "Could not parse" message I got previously, there's now
no accompanying message.

Post by Matthew Peters
Incidentally, could you paste in a little of the code that used to add
the fields to the entry? I am finding it very hard to write the code
that creates an entry - something to do with the weird many-valued
nature of entry and author....

OK, here are the gory details. These are mostly open (therefore
typically multi-valued) sequenced types, which is why the code is rather
cumbersome:

$entry = $document->getRootDataObject();

$entry_author = $entry->createDataObject('author');
$entry_author->name[] = $author;

$entry_title = $entry->createDataObject('title');
$entry_title->getSequence()->insert($title);

$entry_content = $entry->createDataObject('content');
$entry_content->type = 'html';
$entry_content->getSequence()->insert(
"I posted this from PHP using SDO");

$category_content = $entry->createDataObject('category');
$category_content->term = "bookmark";
$category_content->scheme =
"http://www.ibm.com/xmlns/prod/sn/type";

if ($categories) {
$categories = (array)$categories;
foreach ($categories as $category) {
$category_content = $entry->createDataObject('category');
$category_content->term= $category;
}
}

$link_content = $entry->createDataObject('link');
$link_content->href = $link;


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters]

Oh dear.

Post by Caroline Maynard
<tns:author>
<name>Caroline Maynard</name>
</tns:author>

.../...

Post by Caroline Maynard
atom namespace. However the problem for me is that this particular
server still doesn't like it - it gives me a response code 400, but

I hoped we had seen the back of namespace problems but this looks like
Tuscany is still generating the wrong XML. <name> should also be
coming out in the target namespace. Once again the generated XML will
not validate with XERCES, whereas if I make <name> into <tns:name> it
will (this is with the extra change to add
elementFormDefault="qualified")

The output shoud be
<tns:author>
<tns:name>Caroline Maynard</tns:name>
</tns:author>

I will open a JIRA.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Caroline Maynard]

Post by Matthew Peters
I hoped we had seen the back of namespace problems

Told you so: http://groups.google.com/group/phpsoa/msg/11a5c7ea4f6dd260 :-)

Post by Matthew Peters
I will open a JIRA.

You'll have noticed that Pete has provided fixes for
http://issues.apache.org/jira/browse/TUSCANY-1564 and
http://issues.apache.org/jira/browse/TUSCANY-1566. These do fix up the
generated xml in the way you describe, and it is probably now valid.

However I am still getting the 400 status code (with no error message)
from the atompub server. I think the code in question just can't cope
with not having a default namespace - it likes:

<?xml version="1.0" encoding="UTF-8"?>
<entry xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.w3.org/2005/Atom">
<author>
<name>Caroline Maynard</name>
</author>
...
</entry>

but dislikes:

<?xml version="1.0" encoding="UTF-8"?>
<tns:entry xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:tns="http://www.w3.org/2005/Atom">
<tns:author>
<tns:name>Caroline Maynard</tns:name>
</tns:author>
...
</tns:entry>

It may non-compliant - and I can try raising this as a problem - but it
probably isn't the only server in the world to work like this.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters]

How beastly of it. Now, who wants to be the one to tell Pete...

Post by Caroline Maynard
However I am still getting the 400 status code (with no error message)
from the atompub server. I think the code in question just can't cope
<?xml version="1.0" encoding="UTF-8"?>
<entry xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.w3.org/2005/Atom">
<author>
<name>Caroline Maynard</name>
</author>
...
</entry>
<?xml version="1.0" encoding="UTF-8"?>
<tns:entry xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:tns="http://www.w3.org/2005/Atom">
<tns:author>
<tns:name>Caroline Maynard</tns:name>
</tns:author>
...
</tns:entry>
It may non-compliant - and I can try raising this as a problem - but it
probably isn't the only server in the world to work like this.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters]

Post by Caroline Maynard

Post by Matthew Peters
Incidentally, could you paste in a little of the code that used to add
the fields to the entry? I am finding it very hard to write the code
that creates an entry - something to do with the weird many-valued
nature of entry and author....

OK, here are the gory details. These are mostly open (therefore
typically multi-valued) sequenced types, which is why the code is rather

Thank you. The mistake I was making was putting
$entry_author->name = $author;
when I should have had
$entry_author->name[] = $author;

Isn't it all horrid. When you try to write it from scratch, and if you
do not know what you are doing (that was me) it's baffling. The code I
had (i.e. without the []) executes, but nothing comes out in the
generated xml, or var_dump, so where the author value goes in that
case I don't know.

And as far as I know there is not an example of it in the examples.
The only places I could see where content was being built up, the code
was using heredocs instead. It looks like our examples need a
considerable overhaul (I am remembering your point 1. above also.)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Caroline Maynard]

Post by Matthew Peters
Thank you. The mistake I was making was putting
$entry_author->name = $author;
when I should have had
$entry_author->name[] = $author;
Isn't it all horrid. When you try to write it from scratch, and if you
do not know what you are doing (that was me) it's baffling.

It is quite horrid, but there is a way you can examine the structures -
if you create an SDO_Model_ReflectionDataObject from the sdo
representing the atom entry, it will show you the details. For example,
the author property is described as:
http://www.w3.org/2005/Atom#personConstruct $author[] {
commonj.sdo#String $name[];
commonj.sdo#String $uri[];
http://www.w3.org/2005/Atom#emailType $email[];
http://www.w3.org/2005/Atom#extensionType $extension[] {
}
}
which was how I knew that $author->name must be many-valued.

Post by Matthew Peters
The code I
had (i.e. without the []) executes, but nothing comes out in the
generated xml, or var_dump, so where the author value goes in that
case I don't know.

Hmm, neither do I. Sounds like an sdo bug.

Post by Matthew Peters
And as far as I know there is not an example of it in the examples.
The only places I could see where content was being built up, the code
was using heredocs instead. It looks like our examples need a
considerable overhaul (I am remembering your point 1. above also.)

Agreed, I only found examples that sent pre-canned xml from heredocs,
which seems to miss one of the benefits of using SCA.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Graham Charters]

The many-valued nature of a lot of the properties is unfortunately due
to the inability of XML schema to accurately describe the Atom
Syndication Format. It's a while since I wrote the schema, but I seem
to recall it was to do with the use of <choice maxOccurs="unbounded" /

. The Atom XML is defined in terms of Relax NG which does a far

better job. On the plus side, the SDO model could do quite a good job
of representing Atom, so one thought I had was to programmatically
build up an SDO Atom model in the binding. Applications could work
with this cleaner version and then in the binding we would use the XML
schema-based version to handle the serialization/deserialization.
Another thought was to define PHP classes to represent the Atom format
and again use the XML schema-based SDO to do the serialization/
deserialization.

I quite like the heredoc approach as an alternative, which is why I
write the sample code to do that :-D

For the XML serialization using the default namespace, would we want
this to be determined from the XML schema? So for example, our
Atom1.0.xsd has the default namespace being that of Atom, so the
instance documents could do the same.

Graham.

Post by Matthew Peters
Thank you. The mistake I was making was putting
$entry_author->name = $author;
when I should have had
$entry_author->name[] = $author;
Isn't it all horrid. When you try to write it from scratch, and if you
do not know what you are doing (that was me) it's baffling.

It is quite horrid, but there is a way you can examine the structures -
if you create an SDO_Model_ReflectionDataObject from the sdo
representing the atom entry, it will show you the details. For example,
http://www.w3.org/2005/Atom#personConstruct$author[] {
commonj.sdo#String $name[];
commonj.sdo#String $uri[];
http://www.w3.org/2005/Atom#emailType$email[];
http://www.w3.org/2005/Atom#extensionType$extension[] {
}
}
which was how I knew that $author->name must be many-valued.

Post by Matthew Peters
The code I
had (i.e. without the []) executes, but nothing comes out in the
generated xml, or var_dump, so where the author value goes in that
case I don't know.

Hmm, neither do I. Sounds like an sdo bug.

Post by Matthew Peters
And as far as I know there is not an example of it in the examples.
The only places I could see where content was being built up, the code
was using heredocs instead. It looks like our examples need a
considerable overhaul (I am remembering your point 1. above also.)

Agreed, I only found examples that sent pre-canned xml from heredocs,
which seems to miss one of the benefits of using SCA.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Graham Charters]

I meant to ask. Of the options to improve the API, which would people
prefer, or are there any other suggestions?

My current preference is for the building up of the SDO Atom model
programmatically because this will not require the developer to
specify they want to use something other than SDO. I think the PHP
class approach might need a new annotation to say they want classes
(POPO - Plain Old PHP Objects) rather than SDO.

Post by Graham Charters
The many-valued nature of a lot of the properties is unfortunately due
to the inability of XML schema to accurately describe the Atom
Syndication Format. It's a while since I wrote the schema, but I seem
to recall it was to do with the use of <choice maxOccurs="unbounded" />. The Atom XML is defined in terms of Relax NG which does a far
better job. On the plus side, the SDO model could do quite a good job
of representing Atom, so one thought I had was to programmatically
build up an SDO Atom model in the binding. Applications could work
with this cleaner version and then in the binding we would use the XML
schema-based version to handle the serialization/deserialization.
Another thought was to define PHP classes to represent the Atom format
and again use the XML schema-based SDO to do the serialization/
deserialization.
I quite like the heredoc approach as an alternative, which is why I
write the sample code to do that :-D
For the XML serialization using the default namespace, would we want
this to be determined from the XML schema? So for example, our
Atom1.0.xsd has the default namespace being that of Atom, so the
instance documents could do the same.
Graham.

Post by Caroline Maynard

Post by Matthew Peters
Thank you. The mistake I was making was putting
$entry_author->name = $author;
when I should have had
$entry_author->name[] = $author;
Isn't it all horrid. When you try to write it from scratch, and if you
do not know what you are doing (that was me) it's baffling.

It is quite horrid, but there is a way you can examine the structures -
if you create an SDO_Model_ReflectionDataObject from the sdo
representing the atom entry, it will show you the details. For example,
http://www.w3.org/2005/Atom#personConstruct$author[] {
commonj.sdo#String $name[];
commonj.sdo#String $uri[];
http://www.w3.org/2005/Atom#emailType$email[];
http://www.w3.org/2005/Atom#extensionType$extension[] {
}
}
which was how I knew that $author->name must be many-valued.

Post by Matthew Peters
The code I
had (i.e. without the []) executes, but nothing comes out in the
generated xml, or var_dump, so where the author value goes in that
case I don't know.

Hmm, neither do I. Sounds like an sdo bug.

Post by Matthew Peters
And as far as I know there is not an example of it in the examples.
The only places I could see where content was being built up, the code
was using heredocs instead. It looks like our examples need a
considerable overhaul (I am remembering your point 1. above also.)

Agreed, I only found examples that sent pre-canned xml from heredocs,
which seems to miss one of the benefits of using SCA.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Caroline Maynard]

Post by Graham Charters
I meant to ask. Of the options to improve the API, which would people
prefer, or are there any other suggestions?
My current preference is for the building up of the SDO Atom model
programmatically because this will not require the developer to
specify they want to use something other than SDO. I think the PHP
class approach might need a new annotation to say they want classes
(POPO - Plain Old PHP Objects) rather than SDO.

We've seen that using SDO can sometimes be quite clunky. But OTOH,
switching between different approaches within the same program is even
worse. And the heredoc approach, while the simplest initially, can't be
abstracted. So POPOs may be the way, but they must be used throughout.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Caroline Maynard]

Post by Graham Charters
For the XML serialization using the default namespace, would we want
this to be determined from the XML schema? So for example, our
Atom1.0.xsd has the default namespace being that of Atom, so the
instance documents could do the same.

Yes, I think that would be the right approach. We'd need this to be a
Tuscany feature though.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---