Hi,

When creating document types from an XML-schema, all elements with the data type “Document” are created with the property “Allow unspecified fields” set to “False”, see attached image. Is it possible to create document types from an XML-schema such that all the “Document”-elements have the property “Allow unspecified fields” set to “True”?

I have tried the following solutions which works but have some problems:

• Break the link to the source xsd and manually edit the “Allow unspecified fields” property. This is not good enough for us since we have to recreate the document types quite frequently and there are hundreds of “Document”-elements.

• Change all occurences of “true” to “false” in the documents ndf files. This feels like a brittle and fragile solution which is not very future proof.

Is there a better way to solve the problem?

Best Regards,
Jesper Andersson

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/fb14ed3edf002cb99a4783c4a07958d8426676c1.jpeg 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/fb14ed3edf002cb99a4783c4a07958d8426676c1.jpeg 2x" data-dominant-color="F6F5F5">

Documenttype.JPG754×342 41.4 KB

Hi Jesper,

is there a dedicated requirement why you want to allow additional fields in your documents which are not described by the xsd underneath?

Both approaches are not really useful.

You can delete the doctypes and the schema node and then recreate them from an updated xsd.
Make sure to name the new objects the same way as the old ones.
The doctype references in the flow services will pick up the new definitions then.
You will only have to map the new fields in this case.

Regards,
Holger

The schemas are for REST-services that we are calling. The service provider updates the schemas once every two weeks. Usually they are just adding a few fields, so we do not want to recreate the document types from the new xml-schemas and redeploy once every two weeks just because of that.

Hello and a Happy New Year,

I think you have to go back to your requirements and discuss with your customer the effort (and therefore, its cost) of continuous schema changes.

Otherwise, you are getting in to a situation where you are allowing yourselves to not honor a service contract your provider is requiring.

IF your provider makes changes in a backwards-compatible manner (that is, the new fields are not required) you should not have to update your schemas as the existing call should work as expected.

Another solution, although fragile, is to wrap the REST calls to your provider in service where you manually alter its signature (which only matches your schema structure and fields by name and not by type).

Good luck,

Hello Gerardo and Happy New Year to you too!

There is nothing we can do about the continuous schema changes of the REST-API that we are using.

Even though the schema changes are “backwards-compatible”, i.e. they add a new field that is optional, we get the following validation error when we validate the REST-response against the document type (created from the XML-schema):
“errorCode=VV-002 errorMessage=[ISC.0082.9026] Undefined Object found”

However, if I change the document type to allow unspecified fields we do not get this validation error.

Other than the two options that I already mentioned in my original post I am considering the following:

• Skip validation of the REST-response altogether

• Create a script which adds any-elements to the xsds

• Create a Java Service which removes all undefined fields in a REST-response

I am not very fond of either of the above though, especially not modifying the XML-schemas.

I have not been able to solve the original problem. However, to get rid of the unspecified fields in the xml string of the REST-response I created a flow service which did the following:

1. pub.xml: xmlStringToXMLNode
2. pub.xml: xmlNodeToDocument
3. pub.xml:documentToXMLString (It seems like this step removes all the unspecified fields if the documentTypeName parameter is specified)

Edit: Step 3 above only removes some of the unspecified fields

Hi,

Would you mind telling me which kind of validation are you doing?

Is it service input signature validation or any of the validate schema services?

Best regards,

Hi Gerardo,

We are using pub.schema:validate.

Best Regards,
Jesper Andersson

Hi,

A suggestion: what if you set “failIfInvalid” to “false” and then check the “error” output for all the cases you know are safe to ignore?

Best regards,

Hi Gerardo,

Thank you for the suggestion, but what I forgot to mention in my previous post is that we are validating when publishing our broker documents as well. In some of our broker documents we use document types generated from the REST-API schemas.

Best Regards,
Jesper Andersson

This is one of the reasons why our default approach is to not validate unless there is a specific reason to do so. Catching format/structure changes “in the middle” can be useful depending upon the processing/eventual target, but IME it is almost always more trouble than it is worth. In the majority of cases where validation in the middle has “caught” a problem, the result from the end point teams is “ignore it.”

Thus, I don’t know if it is workable for your specific scenarios but you might consider turning off validation of the XMLs and during publish. Just pass things through and enforce things if needed either at the end points themselves or as close as you can to the end point using something other than XSD-based validation.

Hi Rob,

Welcome back and good to see your posts actively after long time!!

Cheers!
RMG