Author Topic: XSD Generation Problems  (Read 3842 times)

Chris Brandt

  • EA Novice
  • *
  • Posts: 14
  • Karma: +0/-0
    • View Profile
XSD Generation Problems
« on: January 06, 2005, 10:10:58 am »
I'm working to get familiar with the XSD generator. I've created a fairly simple schema package with four complex types and five simple types.

First problem is that I've set a targetNamespace and Prefix for the package, but I can't get this prefix to be used when referring to simpleType that is an enumeration (ie, not stereotyped as an XSDSimpleType). The example given in the documentation gets around this by not specifying a targetNamespace.

Second problem is that the generator seems to always put an empty import element at the start of the shema (<xs:import/>). I can't figure out how to get rid of this, and my XMLSpy complains about it.

A couple of other notes:

It would be nice if the generator produced an error if the prefix chosen interferes with another, like xs, it took me a couple of hours to figure out that I had stupidly chosen the same prefix as the generator uses for the schema definition.

If you set a targetNamespace but no prefix, local element types are prefixed with the full namespace. I thought this was ok, but XMLSpy is complains that it's an undefined type. I havn't investigated further because the problem goes away when a prefix is used.

atingley

  • EA Novice
  • *
  • Posts: 12
  • Karma: +0/-0
    • View Profile
Re: XSD Generation Problems
« Reply #1 on: January 26, 2005, 11:44:59 am »
You're getting the <xs:import/> element generated because your package (stereotyped with <<XSDSchema>>) references classes outside of its own.  Put all your classes inside one package and this will go away.

Of course, there are cases where you would like to reference classes outside a given package.  I have experimented with this, and nowhere do I find a way to specify the value of the "schemaLocation" attribute on the <import> element.

Have you or anyone else figured out a way to specify the <import>ed schemaLocation during schema generation?
Al

benc

  • EA Administrator
  • EA User
  • *****
  • Posts: 200
  • Karma: +0/-0
    • View Profile
Re: XSD Generation Problems
« Reply #2 on: January 31, 2005, 04:39:38 pm »
Hi,

Thanks for the note.

First Problem : Is this what you are after :

<xs:complexType name="MyType">
...
  <xs:element name="MyType.Kind" type="myns:MyEnum"/>
...

where the reference to MyEnum is prefixed by the targetnamespace prefix "myns"? You should be able to achieve this by creating MyKind as an enumeration stereotype (available from the XSD profile) and ensuring that its pacakge uses "myns" as the targetNamespacePrefix tagged value. Let me know if this doesn't work for you, or if I have misinterpreted your intention.

Second Problem : As atingley mentioned - it's because you referenced types from another package. To specify the schemaLocation put a tagged value on the referenced package called "schemaLocation" with the appropriate value. This is mentioned the xsd doco, but is not defined in the profile - I'll add this.

(Note you can also use the targetNamespace and targetNamespacePrefix tags on the external package, to affect the import statement and xmlns attributes)

Third Problem (re: xs prefix) : Fair comment, I think ideally users should also be able to choose the prefix for the xsd schema elements (eg xs or xsd). In general though, it's probably best to avoid using these for your own namespaces ...

Fourth Problem (re: full namespace prefix) : The schema generator appears to be at fault here- it shouldn't be inserting the full namespace path. I think the only valid options for qualifying the types in the schema are :

a) use a targetNamespace prefix based on a defined targetNamespace. In EA, use the targetNamespace and targetNamespacePrefix tagged values on the schema packages.

b) Use no prefix (which means the default namespace for the schema must be set appropriately). In EA set the defaultNamespace tagged value on the package being generated.

I hope this helps/explains.

Regards,
Ben