[xsd-users] Namespace mapping problem

Tue Jan 20 09:21:21 EST 2015

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.

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).

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5625 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20150120/6aa0ec26/smime.bin