[xsd-users] Namespace mapping problem

[Andre Vautour]

Hi Joe,
See my comments inline. Also, please note that, unlike Boris, I am 
simply a user of the tool.

Cheers,
André

On 2015-01-20 10:21, Gagnon, Joseph - 0558 - MITLL wrote:
> Boris,
>
> I think the problem is associated with the fact that the targetNamespace
> attribute in the XSD is not a "real" URI. As an example, when I run a simple
> test schema like the following:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns:sc="http://www.somesite.org/" targetNamespace="http://www.somesite.org/"
> elementFormDefault="qualified">
> 	<xs:element name="Message" type="sc:MessageType"/>
>        ...
> </xs:schema>
>
> I get the following from XSD:
>
> PS C:\Users\jo24447> C:\Users\jo24447\Downloads\xsd-4.0.0-i686-windows\bin\xsd
> cxx-tree C:\Users\jo24447\ServiceContract_Message.xsd
> C:\Users\jo24447\ServiceContract_Message.xsd:2:166: error: unable to map XML
> Schema namespace 'http://www.somesite.org/' to C++ namespace
> C:\Users\jo24447\ServiceContract_Message.xsd:2:166: info: use
> the --namespace-map or --namespace-regex option to provide custom mapping
>
> If I change the target to something I know is a valid existing URL (e.g.
> http://www.google.com) the error above no longer occurs (although I do get
> other errors that appear to be related).
>
> To be honest, I don't really understand the purpose or behavior of the
> targetNamespace attribute or what requirements must be met when it's specified
> and what it is used for when a schema is compiled or parsed.
In XML, namespaces are simply used as a mechanism for scoping names to 
avoid duplicate names when using elements from multiple different schemas.
While it is common for a namespace name to be a URI, the W3C doesn't 
even mandate it to be a URI, so, it certainly doesn't need to be a URL 
that exists and is valid. Using a URI simply increases the chances that 
the namespace name will be unique.

Since the namespaces are used in XML to avoid duplicate names, it stands 
to reason that the generated code needs to maintain that scoping, else 
it could result it duplicate types in the generate code. I believe that 
the default behaviour of the tool is to maintain the namespace name of 
the XML schema, but it can only do so if the namespace name is also a 
valid C++ namespace name. When it isn't, the tool needs information to 
know how to map the XML namespace name to a valid C++ namespace.

In your example, with namespace http://some-oms-website.mil/, the tool 
would have generated the following code which isn't valid C++:

namespace http://some-oms-website.mil/
{
     class ... {};
}

With the mapping suggested by Boris (--namespace-map http://some-oms-website.mil/=SomeCppNamespace), it would instead generate:

namespace SomeCppNamespace
{
     class ... {};
}

So, the namespace mapping option basically says, for each element/type 
in a XML namespace, generate the associated C++ classes in a C++ 
namespace with a given name.

> After some more experimentation I was able to get my simple schema to be
> successfully processed by XSD (see below). For this to happen, I needed to
> remove the namespace specifier and the targetNamespace attributes. The schema
> is fully self-contained anyway (and as I mentioned earlier, I don't understand
> the namespace attributes very well).
>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="qualified">
>
> This time XSD runs without error and produces a single .hxx and .cxx file,
> each named after the schema file name (I was expecting different types to be
> broken out into separate files).
See the --file-per-type option.

> So, success at last. However, this does not solve a larger issue for me that
> is probably due to the way the "real" schema I'm using is constructed. A
> little background: I have no control over the schema. It is owned by another
> organization. It does consist of multiple XSD files. It has a similar
> situation to what I described for my simple test case above in that the
> targetNamespace URI does not exist (at least not as far as I am able to
> determine). Unfortunately I am not at liberty to provide any other information
> about the schema to you.
As Boris had mentioned in his reply, I believe the most helpful piece of 
information would be to provide the namespace mapping options that you 
tried on the original, unmodified schema. I believe you said you tried 
using the --namespace-map option. Could you provide the exact 
command-line options that you tried that did not work? Are you sure you 
used the same namespace URI (case, trailing slash, etc.)?

While you might not be able to provide the original schema, could you 
instead provide a test schema that reproduces the issue you have 
encountered?

>
> I realize this is probably not very helpful, but I have no choice in the
> matter.  If you have any suggestions, insights or general knowledge to impart,
> please feel free to do so.
>
> Thanks,
> Joe Gagnon
>
>
> -----Original Message-----
> From: Boris Kolpackov [mailto:boris at codesynthesis.com]
> Sent: Monday, January 19, 2015 8:23 AM
> To: Gagnon, Joseph - 0558 - MITLL
> Cc: xsd-users at codesynthesis.com
> Subject: Re: [xsd-users] Namespace mapping problem
>
> Hi Joseph,
>
> Gagnon, Joseph - 0558 - MITLL <Joseph.Gagnon at ll.mit.edu> writes:
>
>> I tried using the -namespace-map and -namespace-regex options but was
>> unable to make any progress.
>>
>> [...]
>>
>> I cannot figure out what is wrong or what I need to do to correct the
>> problem.  I'm not sure if I used the --namespace* options correctly,
>> although the --namespace-map option seemed pretty straightforward.
> Since you haven't provided any concrete information on what you have tried and
> what exactly doesn't work, I can only say that the --namespace-map option has
> the following general usage:
>
> --namespace-map http://some-oms-website.mil/=SomeCppNamespace
>
> It is indeed very hard to misuse.
>
>
>> As a side note, I had originally run XSD with no options, but got the error:
>>
>> C:\Users\jo24447\xml_output\config\IE6\OMS_Extension_IE6_ExportControl
>> led.xs
>> d: warning T004: generating parsing functions for 13 global elements
>>
>> C:\Users\jo24447\xml_output\config\IE6\OMS_Extension_IE6_ExportControl
>> led.xs
>> d: info: use --root-element-* options to specify document root(s)
> This is not an error. It is a warning.
>
>
>> I'm not sure what 13 global elements it was referring to, but decided
>> to add the --root-element-all option.
> In XML Schema every global element is a valid document root element.
> But global elements are also often used for other things (e.g., to 'ref' in
> multiple places or for substitution groups). At the same time there is
> normally (but not always) only one actual document root. As a result, when
> your schema has multiple global elements, XSD will assume that all of them are
> valid root elements and generate a set of parsing/serialization functions for
> each of them. Since this is normally wasteful (code bloat), XSD issues this
> warning.
>
> Boris