XML Schema Import and Generation

[mover]

I've been involved for 3-4 years in development of transaction schemas for use within our industry. More recently I've started using EA to design and document VB.NET development projects and found it to be quite useful. As a result, it occurred to me recently that it would be really neat if I could design a schema in EA and then generate it based on the design.

The difficulty comes in because we already have a library of schemas, including several base (resource) schemas, that we re-use in all of the transaction schemas. As a result I'm expecting to have to import some of these schemas into my model in order to utilize the types defined in them.

I've imported one of these schemas into EA and it seems that some elements have become "disconnected" from their structures. For example: in on of the structures (which deals with terms) the original schema offers a choice between 4 children.
  1) discountDescribedDate
  2) discountDueDate
  3) discountDueDayOfMonth
  4a) discountDueDays
  4b) discountBasisDate

4a and 4b are used as a pair. The model shows only discountDueDate (#2) and discountBasisDate (#4b) within the choice. The other 3 elements, discountDescribedDate (#1), discountDueDayOfMonth (#3) and discountDueDays (#4a), exist only as simple or complex types with no element in the structure that uses them. Furthermore, if I turn around and regenerate a schema based on the model, it doesn't match the original (it does match the model). I expect that this could be related to the way that we've structured our schemas and it may be that a profile could be created to resolve this.

From there, I decided to see if I could create a model from scratch that would generate an equivalent schema (I've actually started with just one structure within the schema). This has been pretty successfull, if a little time consuming, but there is one issue I haven't been able to find a way around. The discountDescribedDate (#1 above) is an empty element with a single mandatory attribute (description) which is an enumerations. I can create this structure by creating an XSDcomplexType named termsDiscountDescribedDateType and an enumeration (termsDiscountDescribedDateDescriptionType). These can be used in a way that looks correct in the model, but generating the schema results in the following:

<xs:complexType name="termsDiscountDescribedDateType">
   <xs:sequence/>
   <xs:attribute name="termsDiscountDescribedDateDescriptionType"
             type="fnBase:termsDiscountDescribedDateDescriptionType"/>
</xs:complexType>

This would be OK if the empty <xs:sequence/> weren't there. Again, this may be something that could be resolved by a customized profile?

Has anyone run into simmilar problems?

Is there a better way to approach this?

Can anyone recommend any resources that would be helpful?

Thanks!

Mike:o

[Paolo F Cantoni]

Hi Mike,

I'm doing a lot of work using XSD/XML as a transfer medium from/between various tools (including EA) to downstream generators and upstream models.

I use a standard XSD interface between all the tools and so I generate instances using automation (rather than, say, XMI).  But down stream I read the XML using tools such as CodeSmith that can process the XML against the XSD directly.

In the past I've noticed that many XSD importers/validators have difficulty resolving certain structures - your complex type with a single element struck a chord...  I assume you have some XSD authoring tool (such as XMLSpy) that you can use to validate the XSDs.  If you have access to the Microsoft XSD.exe you can use it to convert the XSD to classes and investigate its output to see if it gives you a clue as to how it interprets your problematic structures.  I found it useful in diagnosing problems and "patterns" that are problematic.  It is likely that since EA is .NET focused, they use the .NET XML functionality (which is driven via XSD.exe).

Finally, I found, in my evolution of understanding of XSDs that I initially started using xs:attribute where I should have been using xs:element.  That is, in your example is termsDiscountDescribedDateDescriptionType metadata about termsDiscountDescribedDateType, or an field in the structure.  If the latter, then it should, in my view, be represented as xs:element.  Once I got around my "confusion" that an attribute of a class becomes an xs:element in an xs:complexType and not an xs:attribute - my XSDs started to "sing".

HTH,
Paolo

[mover]

Thanks Paolo!

Yes, I do have XMLSpy; in fact that's the tool that was used to create the schema in the first place.

After a bit of futzing around with XSD.exe, I was able to get it to generate classes for the termsType portion of my schema (I'm using that structure to test with). The results were definitely not what I expected! In fact, the "choice" I described in my first message was implemented as an enumeration!

I suspect that you're right about the elements vs. attributes. The particular complexType in question seems to me to be better suited to an element than an attribute. Unfortunately, this is a schema that was created about 5 years ago and is in production, so it will be dificult to change.

Do you have any thoughts on how to get rid of the extra xs:sequence element that is being inserted into the schema output?

Thanks again!

Mike:o