[xsd-users] Error report for XSD-4.0

[Boris Kolpackov]

Hi Alexander,

alexander.gosling at kongsberg.com <alexander.gosling at kongsberg.com> writes:

> 1.
> I did not mean that this is an error in your code. It is just that it 
> is not robust to what happens in user code it is included into. In our 
> case msxml.h gets included into our code for a reason I am not able to
> find within 30 minutes of work.

Ouch ;-). One thing you can try is add an #error directive as a first
line in msxml.h (first make a backup copy though):

#error MSXML is included!

Then try to rebuild your application. If I remember correctly, VC++
will show you the #include stack that triggered the error.


> By not prefix DOMDocument by its namespace in the XSD code it causes 
> an ambiguity between msxml::DOMDocument and xercesc::DOMDocument.
> I think it is a good practice to always prefix types with their 
> namespace in API include files as you can not know what context 
> it is included into.

The DOMDocument name in question is inside a function body. At
the beginning of this body there is 'using namespace xercesc'. If
we can't rely on this working, then we will have to fully qualify
all names all the time. This is a huge burden and code readability
and maintainability nightmare. Especially seeing that there is more
and more template code (which has to be in the headers). Plus, this
is still not going to work if someone does this:

#define DOMDocument MyStuff

The point I am trying to make is that we have to draw a line
somewhere when trying to be "robust" in the face of "incorrect"
client code.

In your case, it is not the fact that msxml.h is includes. There
is also should be something like this somewhere:

using msxml::DOMDocument;

Which essentially makes MSXML's name unqualified. This is a well
known "do not do this" in C++.


>2.
>         Line 17: --include-regex %.*xml-mod.h%Jade/OpenGIS/xml/xml.h%

I noticed that the schema that you are compiling is called xml.xsd, not
xml-mod.xsd. So the above should probably be changed to xml.h (and in
other places).


> 3.

I will look into this in the next few days.

Boris