that atom.xsd file can be found at http://www.kbcafe.com/iBLOGthere4iM/atom.xsd if that helps.

Thanks for raising the defect. Just to let you know: we are working on it. There's two problems - 1. there's something in the xsd that causes us a problem 2. the exception that is thrown is not getting through to where it should so we just get Aborted instead of printing out the exception message. We are looking independently at both problems.

The stack trace and xsd file were helpful. We'll be in touch.

Just checked in new versions of SDOSAX2Parser.* - they change the behaviour so you get a message saying parse problem, but then just termination. The exception still is not getting through. Still working on it.

Apologies, my test case was wrong and so my last message was wrong. With the SDOSAX2Parser.* files checked in yesterday you do now get the exception thrown with useful text. 

We find with the atom.xsd that the exception message mentions a problem with contentType (I think, from memory). We examine the xsd file because we need to construct our own internal model in terms of SDO types and properties. The reason this causes us problems is that it is a type that is based on a string but also has properties. This is not something we have tried to model so far. We have gone back to the architect to see exactly how this should be expressed in the SDO model... We'll be in touch.

We're still waiting on an answer from the architect regarding how we should model "contentType". To confirm, at the moment we take the restriction with base="xs:string" as a trigger to define it as based on an SDO string, and then the extra content catches us out.

BTW, we read through the xsd and see another problem that will surface if we fix the first. The xs:any, also in contentType, is going to cause us a problem. We need to model that as a so-called SDO 'open' type, which is a type that can handle XML mixed content and have extra properties added dynamically. Although the java version of SDO has support for open types we haven't added it yet to the PHP version. I don't expect that we will get to it for some months, though. Sorry.

In case you're interested, the rules that we have to follow when mapping XSD schema -> SDO model are in the SDO 2 spec which is pointed to by http://news.php.net/php.pecl.dev/2612
and the particular rule is the bottom cell of the table on p. 75. That's probably more information than you ever wanted :-)

Well, there are two aspects to this.

The first is the fact that it used to give a segmentation fault, which I think we have fixed. For that reason I propose to close this bug as fixed, if you agree. That leaves the fact that we do not handle the atom.xsd that you supplied.

On that second point, which I am happy to accept as a new bug or feature request if you like, we have had some different opinions.

One opinion is that there is a problem with the XSD. We get this error from the xml parser on the original XSD at http://www.kbcafe.com/iBLOGthere4iM/atom.xsd:
[Error] atom.xsd:147:38: src-ct.1: Complex Type Definition Representation Error for type 'contentType'.  When complexContent is used, the base type must be a complexType.

We don't see that error when we try to parse the xsd to produce the SDO model, because we use libxml2, which does not pick this up.

We understand from Sam Ruby that the official schema for Atom is expressed in RelaxNG:
http://www.atomenabled.org/developers/syndication/atom-format-spec.php#schema
and we have no RelaxNG parser.

Sam also told us that there are conversion tools, but people have had varying results with them:

http://www.relaxng.org/#conversion

All in all, I don't see us being able to use this exact xsd without problems for a while to come.

Let us know what you would like to do with this bug report.

Seems to core dump when I change the charset
(See http://bjori.php.is/sdo/windows.phps) - at least on windows. Have *no* idea have to generate backtrace on windows, will try to make some further tests before we close this.

Got a friend to generate backtrace on linux, see http://www.edu.lahti.fi/~eeron/php.txt
Got no idea where these warnings come from, could be his setup (either way, another matter).

Haven't had much time to dig deeper into this matter, and probably won't have until next weekend.

This bug-report was orginally written cause of segmentation fault when exception didn't get through to user, which is fixed, thanks (closing report).

The latter (charset) is another bug, mistakenly reported here (seems to be dupe of #5297, which is marked as fixed).

contentType/complexType issue is not directly related to SDO, afaict, so should be disregarded untill someone belives otherwise and submits feature/change request :)