Hi, we have evaluating CAM and found some problems that make CAM unusable. Wondering if we doing something wrong:
1. Lack of Namespace or potentially conflicting namespace depending how they are handled via Dictionary
2. Some of our existing XSD when imported lose data: when imported child data is lost for most of the xsd. When exported it also reflects this.
3. Using already accepted XSD schemas by our tools, when imported then exported nothing changes however the created XSDs are generated as 2 separate files at times and if not there are namespace and other naming issues
4. Through Java using the exported xsd it creates a class with no namespace even when the “include namespace” is enabled. While it creates the object and you can use it, the above issues of missing child elements causes the xsd to not have all of the data.
thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
v3.2.1 is in the works right now - and we have addressed some XSD importing issues. It is an ongoing process however - and we cannot fix what we do not know/see! The XSD syntax allows a bewildering array of options and ways of doing things. People have their own patterns and methods.
Any chance you could share one of your XSD schema - so we can take a deeper look?
Thanks, David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
YPritzke, just following up here. Another thing to look at is how the XSD schema syntax is referencing those missing components. There are complex abilities with extension, and more that XSD allows plus potentially conflicted namespaces. You may be able to change those for a simpler mechanism that directly addresses the components - or you could send an example fragment of the XSD syntax that is breaking and not bringing those components into CAM editor.
Thanks, David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
David, thanks to getting back to me. I asked our developers to send you more info on the issues. Another question
Why when we exporting xsd schemas all strings are exported as separate types and not strings? How can we avoid that?
<xsd:element name="FirstName" type="tns:FirstName"/>
<xsd:element name="LastName" type="tns:LastName"/>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Types not strings - we have a new "inline" mode available for the v3.2.1 release that will support that and make the simple xsd:string declaration.
I'm hoping I can get the v3.2.1 out for next week - but every time I say that - I can stymied with other things that eat my weekend/work time and completing the regression testing and resolving one outstanding XSD import issue! Fingers crossed...
David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, we have evaluating CAM and found some problems that make CAM unusable. Wondering if we doing something wrong:
1. Lack of Namespace or potentially conflicting namespace depending how they are handled via Dictionary
2. Some of our existing XSD when imported lose data: when imported child data is lost for most of the xsd. When exported it also reflects this.
3. Using already accepted XSD schemas by our tools, when imported then exported nothing changes however the created XSDs are generated as 2 separate files at times and if not there are namespace and other naming issues
4. Through Java using the exported xsd it creates a class with no namespace even when the “include namespace” is enabled. While it creates the object and you can use it, the above issues of missing child elements causes the xsd to not have all of the data.
thanks
YPritzke, we appreciate you reporting issues.
v3.2.1 is in the works right now - and we have addressed some XSD importing issues. It is an ongoing process however - and we cannot fix what we do not know/see! The XSD syntax allows a bewildering array of options and ways of doing things. People have their own patterns and methods.
Any chance you could share one of your XSD schema - so we can take a deeper look?
Thanks, David
YPritzke, just following up here. Another thing to look at is how the XSD schema syntax is referencing those missing components. There are complex abilities with extension, and more that XSD allows plus potentially conflicted namespaces. You may be able to change those for a simpler mechanism that directly addresses the components - or you could send an example fragment of the XSD syntax that is breaking and not bringing those components into CAM editor.
Thanks, David
David, thanks to getting back to me. I asked our developers to send you more info on the issues. Another question
Why when we exporting xsd schemas all strings are exported as separate types and not strings? How can we avoid that?
<xsd:element name="FirstName" type="tns:FirstName"/>
<xsd:element name="LastName" type="tns:LastName"/>
Appreciate that - look forward to their input.
Types not strings - we have a new "inline" mode available for the v3.2.1 release that will support that and make the simple xsd:string declaration.
I'm hoping I can get the v3.2.1 out for next week - but every time I say that - I can stymied with other things that eat my weekend/work time and completing the regression testing and resolving one outstanding XSD import issue! Fingers crossed...
David