I’m trying to understand the use of the xsi namespace in the root tag of an xml document.
<purchaseorderwood>
…
</purchaseorderwood>
webMethods can not read my document with the xsi entry but if I remove it the problem goes away.
I get the following error:
Could Not Obtain the Sample View Data

com.wm.lang.xml.WMDocumentException: [ISC.0042.9329] No namespace declaration defined for attribute xsi:noNamespaceSchemaLocation in element :PurchaseOrderWood

Tech support has been looking at it since Monday of last week but has been unable to find an answer.

Has anyone experienced this before?
TIA

Ok, so Mary,
Can you provide the actual XML that you are sending to webMethods?
I would like to see all of the tags.

Thanks
Ed

Hi Ed,

The document is actually a PO sent by a customer. The sample attached has gone through documentToXMLString and it’s the xmldata. There were three attributes defined for queryXMLNode and this is where the error occurred.

If the attributes were removed from queryXMLNode, the document runs through fine.

If the attributes and the xsi:noNamespaceSchemaLocation were kept in the document it creates the error listed in the previous post.

If the attributes were kept in the document and the xsi:noNamespaceSchemaLocation was removed, the same error message is displayed.

If the output from the documentToXMLString is loaded as a sample document in TN console as a document type definition, it cannot be read and will have similiar error. If this output has the noNamespaceSchemaLocation in it and with attributes removed, TN cannot read this. Yet this is the same document that was originally read in and recognized by TN. The difference is that it has gone through validation against the schema.

Does that mean the noNamespaceSchemaLocation has to be defined in the schema and where would you do this ?

TIA

Mary,

Here’s some more background that you may find useful. One of the first things to realize is that the Namespaces in XML specification (available from the W3C Web site) describes how namespaces are to be declared in an XML document. Essentially, you need to add a declaration like ‘xlmns:xsi=“xxx”’ in your root element if the element uses an attribute with the xsi namespace.

The xsi namespace is defined by the W3C’s XML Schema Definition Language (XSDL) for the purpose of providing schema-related information in an XML instance document. XML Schema relies quite heavily on namespaces for several purposes. In this case, the NoNamespaceSchemaLocation attribute would allow you to specify the location of a schema to be used for validation of elements with no declared namespace. Elements that do declare a namespace can be validated against the schema associated with that namespace.

Now it’s entirely possible that you could just remove the offending attribute, but then you may not be able to validate the document. Either way, the current document seems to be making improper use of namespaces. HTH. I’d provide more details, but time is of the essence these days. You should be able to find out more on the W3C site.

Hi Michael,

Thanks for your valuable help. Your suggestion did resolve my problem. I added xmlns in front of xsi and everything worked beautifully !

I do still have a question regarding the declaration.

If a document is declared with xsi to start rather than xmlns, how does one go about checking for errors if it doesn’t register any error messages/codes in TN (ie. the processing & user statuses indicates DONE and nothing is executed after the document is put into TN).

If I manually trace to queryXMLNode, the system will display the error message in the discrepancy (no xmlns in front of the xsi). The error message is:

Could Not Obtain the Sample View Data

com.wm.lang.xml.WMDocumentException: [ISC.0042.9329] No namespace declaration defined for attribute xsi:noNamespaceSchemaLocation in element :PurchaseOrderWood

I need to capture or get notified any documents that did not get mapped as a result of incorrect defintion.

Thanks again
Mary

Hi Mary,

There are a couple of things you can look into doing. First, ensure that you’re using the “best practices” approach to error handling recommended in GEAR, and discussed here on several occasions. This of course involves a structure of sequence steps that form a kind of Try/Catch block. This should allow you to trap the exception from queryXMLNode and handle it accordingly.

If this isn’t working for you, you might want to try validating the document when it’s received by TN (simply check the appropriate box in the TN Doctype or Processing Rule). Be warned however, that this can carry a performance penalty. So if high throughput is an issue you should consider this carefully. If you do end up doing this, TN should catch the validation error, log it as such and not process the document. Again, HTH.