XML Spy definition in webMethods

I have a question regarding XML choice format from XML Spy. How do you define the schema in webMethods to reflect this choice format ? The data may vary depending on the choices.


There are a couple of ways to go about this, depending on your situation. If you already have a schema (XSD - created via XML Spy), the easiest thing to do is to build the webMethods document type from it. Right-click on the folder where you want to create the new document type and select “New->All Choices …” (this lets you use the wizard instead of defaulting to a blank document type). From the choices, select Document Type/Next, Enter name and folder/Next, then select “XML Schema” as the source and you can browse to your .xsd file. Select Finish and the wizard should generate a new Document Type based on your schema. I believe it may also create a schema object in the same folder automatically.

If you already have a webMethods document type and you just want to set the choices for an element/node in the document, right-click on the element in question and select Properties. The properties dialog will let you specify that this should be a choice list (and provide allowable values).

Your last statement may be more challenging. It sounds like you’re referring to what’s typically called a co-constraint. This is where you want to specify that “if element A is x, then element B can be y or z”. This type of constraint isn’t supported by XSDL or webMethods, as far as I know. There are some less-widely accepted schema languages that let you do this sort of thing (schematron, RelaxNG, etc.), but that’s a whole different ball game. HTH.


If you are talking about given choices for an element in xmlspy and then bring it as a document in IS to validate against the schema then you should look at how to set enumerations in xmlspy. Then save the schema and create the document based on this schema. This will create the correct IS document and IS schema for you.

If that is not the case, then I guess Michael had explained it to you.


Michael & Thahir,

Thank you both for you help. Apparently XMLSPY created the WM schema correctly because I can see ‘choice’ checked off on the WM schema. I do have another scenario where a document reference is created in the WM Schema from a XML mandatory single element in XMLSPY. Where is this information indicated or dictated to WM as a document reference rather than a string ?



Wow…You flew above my head. Could u explain that a bit more in detail


Well there are two reasons I can think of off the top of my head, Mary. If the schema that XML Spy generated defines the element outside of its context (standalone, if you will) and then uses it via an element ‘ref’ where it actually appears, this would seem to be the driver for webMethods to create a document reference.

Another possible scenario is that the element simply existed already somewhere else as a document, so webMethods just referenced it instead of defining a new node. I’m not really familiar enough with the internal processing to say if this is feasible, though.

Let me know if that’s unclear and I’ll try to be more specific.

Hi Michael,
I think I understand what you’re saying, but I don’t really know XMLSPY well enough to understand what you mean by a standalone context. The element in question is a separate XSD which is referenced by the main SXD. (ie. Purchase Order header as the main XSD which references product XSD).

The layout for the product XSD is a sequence in which it contains a variety of options such as a sequence(second one), a single optional element and a choice.

In the second sequence I have a product identifier which is a mandatory single element and product description which is an optional element(made the mistake of saying it was mandatory in my previous post). The details for product description indicates it is a complex content and the maxoccurs is unbounded. How can I tell if the product description is an element ‘ref’ (the creation of the record reference in WM)?

Thanks for helping

Well here’s the simplest way I know of to find what I’m describing Mary. Open your product schema in XML Spy and select the text view from the tool/menu bar. Find the definition for your product description element (there should be a search function in this view, I believe).

If the definition reads:

<Element name=“xxx” …

then the element is defined right there (inline) and should probably appear as a string or document in wM. However, if the definition reads:

<Element ref=“xxx” …

then the element is actually defined somewhere else and will probably end up as a document reference in wM. HTH.

The field in question is definately an element ref. It was discovered that I did not set the format or validation against the document type and schema in IS for the document type details in TN. I am now getting the description for the product.

Thank you for all your help !