[phpsoa] Re: Experiences with the ATOMPUB binding #5
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.
On 30 Aug, 09:29, Graham Charters [EMAIL PROTECTED] wrote:
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.
On 23 Aug, 20:45, Caroline Maynard [EMAIL PROTECTED] wrote:
Matthew Peters wrote:
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.
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.
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@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: Experiences with the ATOMPUB binding #5
Matthew Peters wrote:
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.
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.
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@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: Experiences with the ATOMPUB binding #5
How beastly of it. Now, who wants to be the one to tell Pete... On Aug 22, 11:33 am, Caroline Maynard [EMAIL PROTECTED] wrote: 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 nameCaroline 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:nameCaroline 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@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: Experiences with the ATOMPUB binding #5
On Aug 20, 12:10 pm, Caroline Maynard [EMAIL PROTECTED] wrote: Matthew Peters wrote: 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: 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@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: Experiences with the ATOMPUB binding #5
Matthew Peters wrote:
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
nameCaroline 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.
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@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
-~--~~~~--~~--~--~---
