default: namespace does not work on valueXPath element for WSDL

[francisu]

2011-06-14 Nightly

Using the explicit namespace (commented out below) gets the desired result, using the "default" namespace does not.

var msgDs = isc.DataSource
		.create({
			ID : "msgDs",
			serviceNamespace : ecNamespace,
	        xmlNamespaces: {ecgrid:"http://ecgridos.net/"},			
			recordName : "ParcelIDInfo",
			recordXPath : "//service:ParcelIDInfo",
			fields : [
					{
						name : "InterchangeID",
//						valueXPath : "ecgrid:Interchanges/ecgrid:InterchangeIDInfo/ecgrid:InterchangeID"
							valueXPath : "default:Interchanges/default:InterchangeIDInfo/default:InterchangeID"
					},

Here is the first part of the response:

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><ParcelOutBoxArchiveResponse xmlns="http://ecgridos.net/"><ParcelOutBoxArchiveResult><ParcelIDInfo><ParcelID>111436402</ParcelID><ParcelBytes>400</ParcelBytes><ParcelDate>2011-06-13T02:38:00</ParcelDate><NetworkIDFrom>99</NetworkIDFrom><NetworkNameFrom>ECGridOS Developer Network</NetworkNameFrom><NetworkIDTo>11</NetworkIDTo><NetworkNameTo>ECGrid Router PDX 11</NetworkNameTo><FileName>file1</FileName><MailbagControlID /><StatusDate>2011-06-13T02:38:33.35</StatusDate><StatusCode>M2400</StatusCode><StatusMessage>ECGRID-IN: Parcel Completed</StatusMessage><LocalStatus>0</LocalStatus><Valid>Valid</Valid><Direction>OutBox</Direction><Interchanges><InterchangeIDInfo><InterchangeID>46299824</InterchangeID><InterchangeProcessDate>2011-06-13T02:38:33.227</InterchangeProcessDate><NetworkIDFrom>99</NetworkIDFrom><NetworkIDTo>99</NetworkIDTo><Standard>X12</Standard><Bytes>400</Bytes><InterchangeControlID>000065264</InterchangeControlID><InterchangeDateTime>2002-05-

[Isomorphic]

Did you take a look at the docs for how the "default:" namespace is established? You seem to be expecting it's a wildcard (matches any namespace); it's not and unfortunately such a thing is not allowed in XPath.

[francisu]

Did you take a look at the docs for how the "default:" namespace is established? You seem to be expecting it's a wildcard (matches any namespace); it's not and unfortunately such a thing is not allowed in XPath.

I did look at the docs which state default namespace is associated with the current default namespace of the XML document (if you look at the XML document attached you see that it uses a default namespace, with an unqualified xmlns attribute). According to the docs "default" is used to match that namespace prefix. I don't expect it to be a wildcard.

[francisu]

Here is the part of the documentation I was looking at:

http://www.smartclient.com/docs/8.0/a/b/c/go.html#attr..OperationBinding.xmlNamespaces

[Isomorphic]

Yes.. but that doc very clearly states what the "default:" namespace prefix will be, and it's not the default namespace on the document.

Then, for non-WSDL-described XML results, if there is a default namespace on the document element, it is made available with the special prefix "default".

For results of WSDL-described operations, the prefix "service" means the service namespace, that is, the "targetNamespace" on the <definitions> element from the WSDL file. The prefix "schema" means the namespace of the outermost element in the output message for the current operation. "default" will be the schema namespace if there is one, otherwise the service namespace.

[francisu]

Apparently not clearly enough because I was able to misunderstand it, and I read it very carefully and spent considerable time trying to make this work. I have read the quick start guide cover to cover and most of the rest of the product documentation.

In my product, when a customer misinterprets the documentation I take that as an opportunity to improve the documentation so that maybe the next person will not have the same problem. I'm hoping you have a similar policy.

[Isomorphic]

We do.. when we see it at least twice :)

If you think the wording can be improved here, please propose alternate wording.

[francisu]

So I guess I don't understand the whole thing here. My understanding is that in the WSDL case the "default" namespace (when used in the valueXPath property) would be bound according to the text that I found in that place in the doc:

"For results of WSDL-described operations, the prefix "service" means the service namespace, that is, the "targetNamespace" on the <definitions> element from the WSDL file. The prefix "schema" means the namespace of the outermost element in the output message for the current operation. "default" will be the schema namespace if there is one, otherwise the service namespace."

Of course there is no reference from the valueXPath element to the xmlNamespaces property of OperationBinding, so it's likely that I made up this connection.

However, I can't then understand what the meaning of the default value of the prefixes is in the context of the xmlNamespaces property. I mean the point of the property is to bind a prefix with a namespace, so I don't understand how default namespace prefixes fit here.

If you can help me understand how this works, I will be happy to propose some text.

[Isomorphic]

Yes, that's the right part of the doc to look at, it's the same one we just quoted.

What might be happening is that while the message itself defines a default namespace, the WSDL file you're using does not define a namespace for that element. We can only tell if you provide the whole WSDL file (and any imports).

Note there's also an "xmlSelect" log category that shows you what the automatically created namespace prefixes are being bound to.

[francisu]

Well the WSDL certainly defines a namespace for the element, otherwise the explicit xmlNamespaces binding in the original code would not have worked, and it works fine. And as you can see from the instance document, the element is defined with a default namespace. I'm happy to provide the WSDL file, but I think I have already evidence that the element in fact has a namespace.

So I think we are back to where we started. I claim that the "default" prefix in the valueXPath should correspond to the default namespace in the instance document (it does not make any sense to reference the default namespace in the WSDL document as that's just a local artifact of the WSDL). Am I correct in this assumption?

If I am, I would suggest the text about the "default" namespace be mentioned in the valueXPath property (and probably recordXPath property). Further your note about the "xmlSelect" log category would be something good to put in that spot in the documentation to help debug these issues.

Please note that I'm not blocked by this as there is an easy workaround for me, and in fact I considered not reporting the problem, but I'm trying to help improve the product by reporting the anomalies that I see.

[Isomorphic]

Well the WSDL certainly defines a namespace for the element, otherwise the explicit xmlNamespaces binding in the original code would not have worked, and it works fine.

No this is not correct. The actual SOAP message defines a namespace, the WSDL may have a flaw, or you may not have caused a dependent XML schema to have been loaded. This is why seeing the WSDL is essential to figuring out what the problem is.

[francisu]

Here you go (it's too big to upload, but here is the link):

https://ecgridos.net/v2.2/prod/ECGridOS.asmx?wsdl