Our project needs to return doc/lit soap messages containing required elements that have been set to null using the xsi:nil=”true” attribute on an empty tag. The elements have been typed as xs:dateTime, xs:decimal, xs:Boolean, etc.The schema describing these elements uses the nillable=”true” attribute to indicate that the element may contain null values. In this case these elements are required and may not be omitted from the message. When creating a simple test to confirm this behavior, pub.xml.schema:validate is not behaving as expected. When attempting to validate a document type created from the following string:

 <ross:personData xmlns:ross="urn:RossSchemaTest" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<name>String</name>
<birthDate>2006-10-09T10:10:00.001-06:00</birthDate>
<age>999</age>
<weeklySalary/>
<nillableInt xsi:nil="true"></nillableInt>
<nillableDate xsi:nil="true"/>
<nillableDecimal xsi:nil="true"/>
</ross:personData>

The nillableInt, nillableDate and nillableDecimal fields fail validation with the following message:

[ISC.0082.9030] Type mismatch, String expected 

The nillableDateTest:validateNillableDate service in the attached package “NillableElementTest.zip” can be used to reproduce this behavior. I have also attached the XSD file “nillableDateTest.xsd” and an instance document “nillableDateTest1.xml” that validates using XML Spy 2006. We are using IS 6.5 SP1.
nillableDateTest.xsd (1.79 KB)
nillableDateTest1.xml (511 Bytes)
NillableElementTest.zip (8.06 KB)

I doubt I’m going to be able to help you on this. You know way to much about schemas and webMethods. I messed around with your service and saw what you were talking about.

I moved the validate step up to just under the xmlStringToNode and then used the node object as input. I then validated against the schema instead of the document. It appeared to work like that. At least it said the validation was okay.

I’m wondering if the way the IS server handles attributes is the problem? What is in the pipeline after the xmlNodetoDocument is not the same in structure as the actual document that is defined. I guess it is suppose to interpret those as attributes but I’m wondering if it really does that.

I had not thought of validating the node object instead of the document. It’s good to know that works, but it should work for the document form as well.

Just another item on my list of things to fix with IS XML schema support. I’ll ask Support to add this to my running features request list.

Mark

When I move the validate step to just after the pub.xml:xmlStringToNode step, I get the following error:

com.wm.app.b2b.server.ServiceException: [ISS.0062.9024] Integration Server does not support this type of object in validation _DOCUMENT_ System ID: null Public ID: null [/i]

[ISS.0062.9024]Did you insert a pub.xml:queryXMLNode step after the xmlStringToNode step?

See attached screenshot of my current service.

Mark

OK, you validated the node against the IS schema rather than the doc type. Works for me now.

So, in summary, if an element contains an xsi:nil=“true” attribute, it will fail validation if validating an IS doc against an IS doc type, but will pass validation if validating a node against an IS schema.

That’s broken, but perhaps workable.

Mark

It does seem broken. Figuring out how the IS server handles XML schema is akin to rocket science which it should not be.

Funny. My current client is in the rocket science business and I still can’t figure it out. Maybe I need some help from these guys.

Mark

Hi Mark C and Mark G,

I am facing similar problem with pub.schema.validate service.

My xml’s root element contains xsi:schemaLocation attribute, I believe it’s valid to have it, cause usr might be using XML spy or some other tool to create their xml from shema. When I try to validate document created from this xml (using xmlstring to Node and then Node to Document) against doc type created from shema it fails with error [ISC.0082.9026] Undefined Object found. Offcourse it validates fine in XMLSpy.

As Mark G suggested I tried putting my validate service before document to xml service. So now I am validating xmlnode against actual schema, instead of IS document against IS Doc Type. And guess what??? Its working !!! :)…

So looks like one more case where validate service is not handling attributes correctly… Am I right to say this or I am missing something or doing something stupid here???

I am sure you guys have tried validating xml which contains xsi:schemaLocation attribute… what is your experience??
Please let me know…

Other option I have is to use pub.string.replace service to search for regular expression xsi:schemaLocation=.*.xsd" and replace with blank to get rid of this from xml string… problem I have is, this regular expression support of replace doesnt have option to specify ignore case… i.e. -i

Any thoughts or suggestions from rocket scientists ???

Thanks,
Regards,
Ajit

I’m guessing that no attributes exist on your root level node in your IS document definition if you generated it from an external XML schema (I haven’t seen it successfully bring in a schemalocation attribute) so when you try to validate an incoming XML instance document that has attributes at that level it bombs out. You can manually add the attributes into your IS document definition using the @ symbol a field name and give it a try. There are samples of this in the built in services guide.

That still may not work however, I wouldn’t get my hopes up. The better solution would be to have the webMethods IS parser go to the external location for validation. Maybe in a future version. For now you can stick to validating against the webMethods IS schema. You just have to remember to keep it insynch with the real external schema.

The real rocket scientist (Mark C) is at Integration World. Maybe he can tear himself away from some of the parties and throw in his opinion.

I’ll need a little time to experiment with this, but the workaround of validating against the IS schema should get you going for now.

I’ve always resisted writing a service to validate an XML instance document against an XML schema in an external XSD file, but may actually need to do this for my current project. If anyone has done this and would like to save me some time, please feel free to post your example here.

Mark
(playing hookie from IW 2006 training session)

Thanks Mark(s),

I had already tried adding attribute in my document with @ and it works… Only trouble is, if in fiture I get updated schema and when I recreate IS doc type from schema, I will have to remeber to add this attribute in doctype manually :)… and it might not be me next time :)…And I have about 20 documents to maintain :)…

Thanks for your help guys… any other ideas !!!

Ta,
Ajit

This issue has now been fixed with IS_6-5_SP1_WebSvcsXML_Fix2 available on Advantage. Also, when converting a node to document type, be sure to specify a document type name and set makeArrays=false for the validation to function properly.

In one of those great hallway conversations at Integration World, Subash Ramachandran, the Director of Product Development for Integration Server, cautioned against using pub.schema:validate to validate populated document types against document type structures (even when the doc type structures were created from XSD files).

His recommendation was to always validate nodes against an IS schema as that validation is “richer” in functionality. I offered, of course, that both ways were supported in the product and should be equivalent in functionality, but I’ve already converted my validation routines for my current project to validate against schemas.

One advantage of this approach is that prefixes are handled automatically as long as the nsDecls parameter was populated with the correct namespace definitions when creating the document type from which the node to be validate was created.

One disadvantage seems to be that validation error messages seem to be somewhat more obscure when identifying missing required elements.

Mark