I get the same result for restriction also:

  <complexType name="ComplexTypeSimpleContentRestrictingComplexTypeType">
    <simpleContent>
      <restriction base="tns:ComplexTypeExtendingSimpleTypeType">
        <attribute name="AddedByExtension" type="NCName" />
      </restriction>
    </simpleContent>  
  </complexType>     
                 
  <element name="RootElement27">
    <complexType>
      <sequence>
        <element name="ComplexTypeSimpleContentRestrictingComplexType" type="tns:ComplexTypeSimpleContentRestrictingComplexTypeType"/>                        
      </sequence>
    </complexType>
  </element>

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PECL.


I think you're probably describing a Tuscany problem, but there's no link in the defect and I don't see an obvious issue which corresponds. Please either add a link, or if this is a problem with the PHP extension, confirm that it still exists with the latest release.

Please find above my description of the problem.
It seems that you can't have a complex type that extends a simple type.

I tried with your new version of SDO 1.2.0, same problem.

<?php 
try { 
   $xmldas = SDO_DAS_XML::create("./ddex_xsd/dsr.xsd"); 
  print($xmldas); 
} catch (SDO_Exception $e) { 
   print($e->getMessage()); 
} 
?> 

but I get this execption : 
Cannot add property Namespace of type commonj.sdo#String to this data 
type http://ddex.net/xml/2006/dsrm/10#CommercialModelType 

Official XSD file can be downloaded here : 
http://ddex.net/xml/2006/dsrm/10/dsr.xsd

WFX

Google group link :

http://groups.google.co.uk/group/phpsoa/browse_thread/thread/a86e9bb59b8f86f5/33cf2d864cad4625#33cf2d864cad4625

The PHP SDO implementation depends on the Tuscany C++ SDO library, and often bugs can only be fixed by getting them implemented in Tuscany. So when a SCA_SDO maintainer raises an SDO bug in this tracker, our rule is that they should always provide a link to the relevant Tuscany defect, to make sure we can trace progress. This particular bug was moved (along with a few others) to feedback state because the there was no runnable testcase and no link to a Tuscany defect. 

Of course when the person raising the bug is not a maintainer, we don't expect you to do this!

This problem should remain open. It is a long standing issue with Tuscany C++ SDO recorded in JIRA TUSCANY-444. Looking back at this I note that Pete added comments to the JIRA a good while back but a solution was not developed. I'll go take a look and see what state the code is in.

Simon, the way we handle these is to assign the bug to tuscany, not to yourself, and to add a link in the defect so that interested parties don't have to find their own way to the Tuscany JIRA:

http://issues.apache.org/jira/browse/TUSCANY-444

Suspending this report as the extension have not had a release for almost 9 years.  Please revive this if the extension once again shows life