I am using gSOAP to create C++ code from a WSDL document. The problem is gSOAP is giving me errors when I run the wsdl2h tool on my WSDL file. The errors are all related to namespace issues. For example
Warning: could not find element 'GetRPCMethods' type '"http://www.broadband-forum.org/cwmp/cwmp-1-2.xsd":GetRPCMethods' in schema urn:tr069
I have pasted the namespace definitions and an example of how they are used below. Anyone know where I am going wrong?
urn:tr069 is supposed to refer to the current document.
<s0:definitions
name="tr069"
xmlns:s0="http://schemas.xmlsoap.org/wsdl/"
xmlns:s1="urn:tr069"
xmlns:s2="http://schemas.xmlsoap.org/wsdl/soap/"
targetNamespace="urn:tr069">
<s0:types>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="urn:tr069"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd1="http://www.broadband-forum.org/cwmp/cwmp-1-2.xsd"
targetNamespace="urn:tr069">
<xsd:import namespace="urn:dslforum-org:cwmp-1-2" schemaLocation="cwmp-1-2.xsd" />
<xsd:element name="GetRPCMethods" type="xsd1:GetRPCMethods" />
</xsd:schema>
</s0:types>
<s0:message name="GetRPCMethods">
<s0:part element="s1:GetRPCMethods" name="GetRPCMethods" />
</s0:message>
</s0:definitions>
I have a few other questions, as I understand it the target namespace does not have to point to a real location, it is just a convention for pointing to the current document, Is this correct? Also in cwmp-1-2.xsd there is an element called GetRPCMethods which contains a sequence containing another element. Is it best practice to use this whole element(GetRPCMethods) as a part for a message as I have above or should I define the specific parts of GetRPCMethods in the message?
Thank you.
The problem was the elements defined in the <schema> tag. First I removed all the defined elements inside the <schema> tag because they were completely unnecessary anyway. Then I changed the namespace of the elements in the message parts from s1 to xsd1 to use the elements in cwmp-1-2.xsd instead of the ones I defined in the <schema> tag.
As for my other questions, the targetNameSpace does not have to point to a real uri, it is just a name for the namespace of this document. For my second question, I think it is probably best and easiest to use the whole schema element as the part for the message.
I notice that
<xsd:schema>
doesn't have a closing tag? Is the wsdl a well-formed XML Document?
Targetnamespace is the namespace of the instance document ie., the one for SOAP:Envelope.
The error message says what's wrong, you don't have a definition of xsd1:GetRPCMethods, is this somewhere defined?
s1:GetRPCMethods is looked up -> s1 is found to be urn:trn069 -> urn:trn069 is not unique which might be a problem -> urn:trn69 defines the element, GetRPCMethods which is of type xsd1:GetRPCMethods -> this type is not found.
I'm not sure if it is valid to use the same URI for the targetNamespace. Maybe that's causing additional problems.
Related
I am getting error as
org.xml.sax.SAXNotRecognizedException: Property 'http://javax.xml.XMLConstants/property/accessExternalDTD' while validating xsd with xml input at date field.
In xsd it is like <xsd:element name="CreateTime" type="xsd:dateTime">
and in xslt it is <xsl:value-of select="current-dateTime()"/>
Please help in solving above issue
The application that invokes the XML parser is asking it not to access any external DTD by setting the property http://javax.xml.XMLConstants/property/accessExternalDTD. This is a "standard" property defined in the JAXP specification, but it was only added in later versions, so older XML parsers do not support it, and throw this error if it is requested.
This is nothing to do with the content of your XML, XSD, or XSLT. It's all to do with the configuration of the software components in your application (which you've told us nothing about: you didn't even mention it was Java.)
I'm trying to search through a site collection and find all sites that contain a particular file. TrimDuplicates is supposed to be the right way to do that. I'm calling QueryEx of the WebService object with the following XML as the string argument.
<QueryPacket xmlns='urn:Microsoft.Search.Query'>
<Query>
<TrimDuplicates includeid="false">False</TrimDuplicates>
<SupportedFormats>
<Format revision='1'>urn:Microsoft.Search.Response.Document:Document</Format>
</SupportedFormats>
<Context>
<QueryText language='en-us' type='STRING'>
"filenameForQuery"
</QueryText>
</Context>
</Query>
</QueryPacket>
The response from search.asmx is a 500 error with System.FormatException as the only piece of useful information.
It's only the TrimDuplicates element that is triggering the formatexception. Fiddling the case of the two Falses hasn't had any effect so far.
The answer is actually blindingly obvious - remove the includeid attribute and make the content of TrimDuplicates lower case.
Just wanted to point out that includeid should actually be an integer value.
More here
But as you said, it's not necessary.
At the momemet I am working on part of my application where I need to parse Relax NG schema and reproduce rules within file in C++ objects. I start with example code so I can explain better.
<!-- property.element -->
<define name="property.element">
<element name="property">
<attribute name="type" />
<interleave>
<zeroOrMore>
<ref name="resource.class" />
</zeroOrMore>
<ref name="literal.class" />
</interleave>
</element>
</define>
I want to create object where I can store information like:
[define] name,
element name,
attribute names,
allowed child elements with associated rules (zero or more, one or more).
Then I want to display all possible elements in my GUI where I can add only valid (in terms of Relax NG schema) elements to tree-like structure. For example - I can add only resource.class or literal.class to my property.element, every other possible element is greyed in my GUI when I have selected property.element node in GUI. I use Qt, so I load schema into QDomDocument to get access to DOM tree.
Such mechanism has to be universal i.e. no matter how elements are named, or how its structure is. In my draft I created simple class where I placed several members like: defined_name, element_name, required_attributes, optional_attributes. Currently I am stuck because I do not have any idea how to represent rules in C++ class. If I had constant set of objects on which I work I would hard-code every object, but my objects set is very likely to change drastically over time. Does anyone have any idea?
Convert the RNG file to XSD using TRANG, then convert the XSD to c++ using CodeSynthesis either XSD or XSDe). There are a bunch of samples with XSDe, so there might be one demonstrating how to validate the xml input with the schema rules.
http://www.thaiopensource.com/relaxng/trang.html
http://www.codesynthesis.com/products/xsde/
I've created an XSLT stylesheet document. Within this document I create a new XML document as stated below:
...
<CREATE_REQ
xsi:schemaLocation="http://fcubs.ofss.com/service/aServices theService.xsd"
xmlns="http://fcubs.ofss.com/service/aServices"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
...
After transformation (see below) the ordering of the namespaces is different. A normal XML parser can handle this and it is normally no problem. The problem in my case is that the receiving application can't handle this and the order of the namespace may and shouldn't be changed.
<CREATE_REQ xmlns="http://fcubs.ofss.com/service/aServices"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://fcubs.ofss.com/service/aServices theService.xsd">
...
Is there a function or declaration that the namespaces will not be changed?
If the receiving application can't handle it then it needs to be fixed. Whoever wrote it doesn't seem to have grasped what XML is all about. Fix the receiving application, or throw it in the bin where it belongs.
After transformation (see below) the ordering of the namespaces is
different.
No, the ordering is exactly the same. According to the W3C XPath 1.0 Data Model:
The attribute nodes and namespace nodes of an element occur before the children of the element. The namespace nodes are defined to occur before the attribute nodes.
This means that although in the provided XML fragment the attribute xmlns:xsi seems to precede the namespace declarations, in fact it follows them.
Therefore, the produced output doesn't change the ordering of namespaces and attributes of the original XML document.
Producing an XML document where an attribute precedes a namespace node would violate the above quoted definition, therefore a compliant XSLT processor wouldn't produce such a document.
XSL requires this at the top of every stylesheet:
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
and throws an error if the url in the namespace is not exactly right.
Today, "http://www.w3.org/1999/XSL/Transform" is offline. I cannot run any transformations. The transformation hangs and then returns "unexpected end of file" when the net request times out. If I change the URL in the namespace declaration to a random URL, the transformation fails with an error telling me that "http://www.w3.org/1999/XSL/Transform" is the required xsl namespace.
So how do I work around W3's site being down?
Using xmlns:something="..." declares an XML namespace. Such a namespace is merely a string, something that will help to attribute a unique meaning to element names like template or href, making sure multiple XML-based languages can be used in a single document without creating confusion as to its meaning.
Some of those namespaces are reserved for use by the W3C. The XSLT namespace is one of those. A proper XSLT processor will check if a stylesheet declares the correct namespace to make sure there can be no incorrect interpretation. The root element of the stylesheet should be in that XSLT namespace.
For an actual namespace value, you'd usually have a URI (and most often a URL) since that's normally a good unique identifier. However, this should never be used to actually resolve to any online resources during XML processing. Whereas HTTP URLs are normally treated in a case-insensitive manner and may make use of URL encoding for characters (e.g. space becomes %20), such resolution or equality of URLs is not checked in XML namespace processing. A namespace in XML is nothing but a string that's always checked in its exact form, casing and everything.
So if an XSLT processor complains that some resource at a URL cannot be found, then either it's doing something it shouldn't do, or the problem has nothing to do with namespace processing.
You're using Saxon, which most definitely isn't a processor that doesn't understand the concept of a namespace. Its father is Michael Kay who is also responsible for the XSLT 2.0 spec. But Saxon does support schema-aware XSLT processing. If a document specifies a schema location, then a processor using this for validation would actually use that location to get the schema. That's the difference with a namespace. DTDs and XML Schema locations can definitely result in network activity.
So I advise you to check if...
the XML uses a DTD with external definitions and whether those are available;
the XML specifies a schema location and whether that location can be reached;
the stylesheet makes use of a schema or some other external resource and whether that's available.
Once you've found the cause, look into the use of XML catalogs in conjunction with the processor. An XML catalog will allow you to use local resources if they can't be resolved from their URIs.
Simple answer: The http://www.w3.org/1999/XSL/Transform isn't a URL, it's just a string. If W3C had decided, there's no reason it couldn't have been 'ThisIsAnXsltStylesheet'. By convention, they usually resemble URL's, but this isn't required.
So, the fact that there's nothing at that URL isn't relevant to why your stylesheet is failing, and certainly won't be the cause. Logically speaking, if that were the case, then nobody without an internet connection would ever be able to use XSLT, and w3c's servers would be seriously overworked.
I'd recommend adding the first few lines of your XSLT into your question; it might shed some light on where your problem really is.