Tuscany
  1. Tuscany
  2. TUSCANY-1073

Not currently possible to generate WSDL - specifically schema - using SDO

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: Cpp-M3
    • Fix Version/s: Java-SDO-Next
    • Component/s: C++ SDO
    • Labels:
      None

      Description

      When I tried to use SDO to generate some wsdl containing a <types> element with some schema, I found that I could
      not generate the contents of the schema, specifically those things that are in the schema namespace. I can't remember
      quite what happened - either the necessary elements were not in the model or not written out, but Ed Slattery explained to me
      at the time that anything in the schema namespace is ignored.

      Please could you fix this so that I can generate wsdl with embedded schema? I currently have a bodge where I have to
      generate all the schema part of my wsdl by hand - lots of string handling - and then stick it into the wsdl at
      the appropriate point and it is all a bit horrid. Fixing this would help a lot.

        Issue Links

          Activity

          Hide
          Matthew Peters added a comment -

          I just tried to put together a test case for this issue, with a progrm that loaded the WSDL, SOAP and schema xsds. I find that things have gone backwards, in that SDO will not now even load the schema xsd any longer.

          If I try to load the xsd schema at http://www.w3.org/2001/XMLSchema.xsd I get an exception from SDO with the text "Type has empty name". It is true that there are types with empty names in this xsd but they are enclosed in elements, and this is allowable. (It is the schema for schema, after all)

          If I google for this text I find it is in Tuscany's DataFactoryImpl.cpp, and if I have read the change history correctly it arrived in a fix to JIRA 763.

          So, we need the schema for schema to load before we can make progress. Do you want me to raise this as a new JIRA?

          Show
          Matthew Peters added a comment - I just tried to put together a test case for this issue, with a progrm that loaded the WSDL, SOAP and schema xsds. I find that things have gone backwards, in that SDO will not now even load the schema xsd any longer. If I try to load the xsd schema at http://www.w3.org/2001/XMLSchema.xsd I get an exception from SDO with the text "Type has empty name". It is true that there are types with empty names in this xsd but they are enclosed in elements, and this is allowable. (It is the schema for schema, after all) If I google for this text I find it is in Tuscany's DataFactoryImpl.cpp, and if I have read the change history correctly it arrived in a fix to JIRA 763. So, we need the schema for schema to load before we can make progress. Do you want me to raise this as a new JIRA?
          Hide
          Geoff Winn added a comment -

          I have reproduced this problem easily enough by loading the XMLSchema.xsd file. Unfortunately, that leads on to some difficult problems. That schema file defines many anonymous types, however the addType method in SDO for C++ requires a type name (and always has). Changing this will be quite invasive since the type name is currently the standard way to identify and access a type. Therefore, there is no quick way to make it possible to load the XMLSchema.xsd file. I would like to defer that problem for the time being and return to the original issue of generating wsdl with embedded schema.

          Show
          Geoff Winn added a comment - I have reproduced this problem easily enough by loading the XMLSchema.xsd file. Unfortunately, that leads on to some difficult problems. That schema file defines many anonymous types, however the addType method in SDO for C++ requires a type name (and always has). Changing this will be quite invasive since the type name is currently the standard way to identify and access a type. Therefore, there is no quick way to make it possible to load the XMLSchema.xsd file. I would like to defer that problem for the time being and return to the original issue of generating wsdl with embedded schema.
          Hide
          Matthew Peters added a comment -

          Thanks for the update. Unless I have misunderstood, though, it will not help for you to be able to generate wsdl with embedded schema, since I will be unable to load a DAS with the XMLSchema.xsd schema file, and hence will not have a DAS that I can use to create any of the data objects that I want to write out in the WSDL. Well, actually I suppose I can do a few addTypes and addPropertyToTypes myself to define the SDO model for the elements of XML Schema that I want: <schema>, <element>, <complexType>, <sequence>, <import>, etc.. Is that what you were thinking?

          Show
          Matthew Peters added a comment - Thanks for the update. Unless I have misunderstood, though, it will not help for you to be able to generate wsdl with embedded schema, since I will be unable to load a DAS with the XMLSchema.xsd schema file, and hence will not have a DAS that I can use to create any of the data objects that I want to write out in the WSDL. Well, actually I suppose I can do a few addTypes and addPropertyToTypes myself to define the SDO model for the elements of XML Schema that I want: <schema>, <element>, <complexType>, <sequence>, <import>, etc.. Is that what you were thinking?
          Hide
          Geoff Winn added a comment -

          Yes, that is what I was thinking. My assumption was that you don't really need the whole of XMLSchema.xsd. Obviously it would be better to just load that and be done with it but since that isn't possible right now, I was hoping that we could create what you need ourselves, within the limits of the current SDO implementation.

          Show
          Geoff Winn added a comment - Yes, that is what I was thinking. My assumption was that you don't really need the whole of XMLSchema.xsd. Obviously it would be better to just load that and be done with it but since that isn't possible right now, I was hoping that we could create what you need ourselves, within the limits of the current SDO implementation.

            People

            • Assignee:
              Unassigned
              Reporter:
              Matthew Peters
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development