From maxim.maslennikov at gmail.com  Mon Mar  2 09:04:46 2015
From: maxim.maslennikov at gmail.com (Maxim Maslennikov)
Date: Mon Mar  2 09:10:09 2015
Subject: [xsd-users] XSD uses a lot of memory
Message-ID: <FB747C77-3109-473C-B7BC-D9633D741E86@gmail.com>

HI,

I created a program of xml data binding test.xsd schema from example folder based on xsd C++/tree and libstudxml persistence.
I tested xsd on OS X and FreeBSD and was surprised xsd version uses in ten time more memory than libstudxml version.

Why does xsd/c++ tree uses memory more?
What?s the reason?
Is it possible to improve it?

Best Regards,
Maxim Maslennikov
Moscow Russia
+7 985 274-05-70

From boris at codesynthesis.com  Tue Mar  3 06:12:51 2015
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Mar  3 06:23:22 2015
Subject: [xsd-users] XSD uses a lot of memory
In-Reply-To: <FB747C77-3109-473C-B7BC-D9633D741E86@gmail.com>
References: <FB747C77-3109-473C-B7BC-D9633D741E86@gmail.com>
Message-ID: <boris.20150303130956@codesynthesis.com>

Hi Maxim,

Maxim Maslennikov <maxim.maslennikov@gmail.com> writes:

> I created a program of xml data binding test.xsd schema from example
> folder based on xsd C++/tree and libstudxml persistence. I tested xsd
> on OS X and FreeBSD and was surprised xsd version uses in ten time
> more memory than libstudxml version.
> 
> Why does xsd/c++ tree uses memory more?

Because C++/Tree is an in-memory mapping. It loads all the data from
the XML document into memory. In contrast, libstudxml is a streaming
parser, it only keeps a very small portion of the document at any
given time (unless you store this data yourself somewhere).


> Is it possible to improve it?

Yes, you can use streaming parser with C++/Tree. See the 'streaming'
example.

Boris

From yury.zaytsev at traveltainment.de  Fri Mar  6 11:22:43 2015
From: yury.zaytsev at traveltainment.de (Yury Zaytsev)
Date: Sat Mar  7 10:03:21 2015
Subject: [xsd-users] Serializer prints xmlns attribute of new elements after
 emitting thousands of them
Message-ID: <1F897018A4B45549AE2FE45B2DFF9E3A9F6BD0@EX-TT-AC-01.traveltainment.int>

Hi,

I've just noticed a strange artifact: when using the streaming serializer, it starts printing out the xmlns attribute of the elements after emitting first few thousands of them. Is there any way I can inhibit this? My setting in pseudocode is as follows:

    xsd ... --omit-default-attributes --root-element Otds ...

    otds::Otds document;
    s.next_open(kNamespaceName, kTagOtds, get_infomap(), document);
    s.next_open(kNamespaceName, kTagAccommodations, accomms);

    for (const auto &accomm: accommodations) s.next(kNamespaceName, kTagAccommodation, accomm);

    s.next_close(kTagAccommodations);
    s.next_close(kTagOtds);

This prints the xmlns attributes for the root element as expected according to my infomap, doesn't print it for <Accommodations> tag as expected, and also for the first few of the <Accommodation> tags, but then mystically at some point new tags are printed like this: <Accommodation xmlns="http://..."> .

I'm very confused by this behavior, and will appreciate any hints as to how this can be debugged. Maybe I'm using the serializer in a wrong way?

Many thanks!

Dr. Yury V. Zaytsev
Senior Software Developer 
IT Data Production

TravelTainment GmbH
Carlo-Schmid-Stra?e 12
52146 W?rselen/Aachen, Germany 
yury.zaytsev@traveltainment.de

http://www.traveltainment.de

Amtsgericht Aachen, HRB 15873
Gesch?ftsf?hrer: Bernhard Steffens (Vorsitzender)
Dr. Oliver Rengelshausen



??? ????????????



From davem at qti.qualcomm.com  Fri Mar  6 14:10:47 2015
From: davem at qti.qualcomm.com (Mckinney, Dave)
Date: Sat Mar  7 10:03:21 2015
Subject: [xsd-users] Error linking with xerces-c_static_3.lib
Message-ID: <788d01cf3964425ea52ffdf204f35e81@nasanexm02h.na.qualcomm.com>

Hi Michael,

Did you find a solution for your xerces static linking problem?
http://codesynthesis.com/pipermail/xsd-users/2013-December/004160.html

I'm having the same problem, so if you can remember what you did to fix it, that would be very helpful.

Thanks,
Dave McKinney
Qualcomm
From maxim.maslennikov at gmail.com  Sun Mar  8 10:20:22 2015
From: maxim.maslennikov at gmail.com (Maxim Maslennikov)
Date: Mon Mar  9 06:08:56 2015
Subject: [xsd-users] XSD uses a lot of memory
In-Reply-To: <boris.20150303130956@codesynthesis.com>
References: <FB747C77-3109-473C-B7BC-D9633D741E86@gmail.com>
	<boris.20150303130956@codesynthesis.com>
Message-ID: <B7854BD0-3F79-4328-8DC1-A6CE951FEF78@gmail.com>

Hi Boris,

I meant my program uses an "object persistance" approach described in your document - "XML Parsing and Serialization in C++
With libstudxml? and also saves all data in memory.
So my question is why does xsd C++/tree use about ten time more memory?
I found it when generated a file of records about 100Mb size.

Best Regards,
Maxim Maslennikov

> On Mar 3, 2015, at 2:12 PM, Boris Kolpackov <boris@codesynthesis.com> wrote:
> 
> Hi Maxim,
> 
> Maxim Maslennikov <maxim.maslennikov@gmail.com> writes:
> 
>> I created a program of xml data binding test.xsd schema from example
>> folder based on xsd C++/tree and libstudxml persistence. I tested xsd
>> on OS X and FreeBSD and was surprised xsd version uses in ten time
>> more memory than libstudxml version.
>> 
>> Why does xsd/c++ tree uses memory more?
> 
> Because C++/Tree is an in-memory mapping. It loads all the data from
> the XML document into memory. In contrast, libstudxml is a streaming
> parser, it only keeps a very small portion of the document at any
> given time (unless you store this data yourself somewhere).
> 
> 
>> Is it possible to improve it?
> 
> Yes, you can use streaming parser with C++/Tree. See the 'streaming'
> example.
> 
> Boris

From yury.zaytsev at traveltainment.de  Mon Mar  9 08:01:49 2015
From: yury.zaytsev at traveltainment.de (Yury Zaytsev)
Date: Mon Mar  9 08:12:48 2015
Subject: [xsd-users] Re: Serializer prints xmlns attribute of new elements
 after emitting thousands of them
In-Reply-To: <1F897018A4B45549AE2FE45B2DFF9E3A9F6BD0@EX-TT-AC-01.traveltainment.int>
References: <1F897018A4B45549AE2FE45B2DFF9E3A9F6BD0@EX-TT-AC-01.traveltainment.int>
Message-ID: <alpine.DEB.2.10.1503091241080.7237@work>

Hi,

On Fri, 6 Mar 2015, Yury Zaytsev wrote:

> This prints the xmlns attributes for the root element as expected 
> according to my infomap, doesn't print it for <Accommodations> tag as 
> expected, and also for the first few of the <Accommodation> tags, but 
> then mystically at some point new tags are printed like this: 
> <Accommodation xmlns="http://..."> .

It looks like I've managed to reproduce this surprising behavior by making 
minor modifications to the standard streaming example shipped with the 
latest version of XSD; please find the diff showing the necessary changes, 
as well as a sample output attached. I've added the loop only to emit a 
just a bit over the required magic number of elements; on my machine the 
threshold seems to be ~500 items.

The effect can be seen in the attached sample output file: the driver 
first outputs the elements as expected, and then starts adding a 
superfluous xmlns="..." attribute to each next element, just as it does 
for me in my setting. Therefore, the problem seems to be independent of my 
specific schema, the way I create elements, etc.

I'm running Ubuntu 14.04 x86_64, latest binary release of XSD, gcc 4.9.2 
and xerces-c 3.1.1-5. Is there any additional information that I can 
provide in order to reproduce this issue?

All the best,

-- 
Dr. Yury V. Zaytsev
Senior Software Developer
IT Data Production

TravelTainment GmbH
Carlo-Schmid-Stra?e 12
52146 W?rselen/Aachen, Germany
yury.zaytsev@traveltainment.de

http://www.traveltainment.de

Amtsgericht Aachen, HRB 15873
Gesch?ftsf?hrer: Bernhard Steffens (Vorsitzender),
Dr. Oliver Rengelshausen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: out.xml
Type: application/xml
Size: 612 bytes
Desc: Sample output.xml
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20150309/9533bb0f/out.xml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: driver.diff
Type: text/x-diff
Size: 1256 bytes
Desc: Necessary modifications.diff
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20150309/9533bb0f/driver.bin
From yury.zaytsev at traveltainment.de  Tue Mar 10 06:58:29 2015
From: yury.zaytsev at traveltainment.de (Yury Zaytsev)
Date: Tue Mar 10 07:34:01 2015
Subject: [xsd-users] Streaming and Xerces-C++ runtime initialization
In-Reply-To: <boris.20150216133100@codesynthesis.com>
References: <1F897018A4B45549AE2FE45B2DFF9E3A9F5914@EX-TT-AC-01.traveltainment.int>
	<boris.20150213115917@codesynthesis.com>
	<1F897018A4B45549AE2FE45B2DFF9E3A9F5961@EX-TT-AC-01.traveltainment.int>
	<boris.20150216133100@codesynthesis.com>
Message-ID: <alpine.DEB.2.10.1503101144500.2048@work>

Hi Boris,

On Mon, 16 Feb 2015, Boris Kolpackov wrote:

> Yury Zaytsev <yury.zaytsev@traveltainment.de> writes:
>
>> While we are at it, do you happen have any plans for inclusion of the
>> serializer in the standard XSD runtime rather than keeping it as an example
>> only? For now, I've hacked up a patch to convert it to use unique_ptr<>,
>> which I can post if it would help, and included it directly in my
>> project. However, since I include the runtime anyways, it would be easier
>> maintenance-wise rather than checking whether anything has changed with
>> every new version, and applying custom patches on top, etc.
>
> The example started with a parser and serializer that had to be customized
> for each vocabulary. Now, however, that they were generalized, I agree it
> would make sense to move them to libxsd. There is one problem, though:
> libxsd is header-only and both of them, and especially the serializer,
> have quite a bit of non-inline source code. So that's an obstacle.

As promised, please find a patch for C++11 support in serializer attached. 
I think that it's a bit cleaner than the other one that is already 
floating around; at least I've tried my best to stick to your coding 
conventions...

For now I'm simply adding the objects to my build system and compile them 
with -DXSD_CXX11 (honestly, I haven't actually tried to compile the 
auto_ptr version, but hopefully it should work).

You are right about the non-inline code, but as far as I understand, if 
you want to keep the implementations separate for maintenance purposes, 
then you can simply rename the *.cxx file to *.ixx and include it from the 
*.hxx file, whereas the static const XMLCh arrays can be wrapped around 
with static get_XXX() member functions in order to avoid linking problems.

Hope that helps,

-- 
Dr. Yury V. Zaytsev
Senior Software Developer
IT Data Production

TravelTainment GmbH
Carlo-Schmid-Stra?e 12
52146 W?rselen/Aachen, Germany
yury.zaytsev@traveltainment.de

http://www.traveltainment.de

Amtsgericht Aachen, HRB 15873
Gesch?ftsf?hrer: Bernhard Steffens (Vorsitzender),
Dr. Oliver Rengelshausen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: serializer-c++11.patch
Type: text/x-diff
Size: 7727 bytes
Desc: serializer-c++11.patch
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20150310/a0fb0277/serializer-c11.bin
From boris at codesynthesis.com  Tue Mar 10 08:05:03 2015
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Mar 10 08:15:33 2015
Subject: [xsd-users] XSD uses a lot of memory
In-Reply-To: <B7854BD0-3F79-4328-8DC1-A6CE951FEF78@gmail.com>
References: <FB747C77-3109-473C-B7BC-D9633D741E86@gmail.com>
	<boris.20150303130956@codesynthesis.com>
	<B7854BD0-3F79-4328-8DC1-A6CE951FEF78@gmail.com>
Message-ID: <boris.20150310140242@codesynthesis.com>

Hi Maxim,

Maxim Maslennikov <maxim.maslennikov@gmail.com> writes:

> I meant my program uses an "object persistance" approach described
> in your document - "XML Parsing and Serialization in C++ With
> libstudxml? and also saves all data in memory.

You mean the data for the *entire* document is stored in memory?


> So my question is why does xsd C++/tree use about ten time more
> memory? I found it when generated a file of records about 100Mb
> size.

If the answer to the above question is "yes", then I will need to
see a test that reproduces this. C++/Tree definitely shouldn't
use 10 times more memory.

Boris

From boris at codesynthesis.com  Tue Mar 10 08:07:11 2015
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Mar 10 08:17:41 2015
Subject: [xsd-users] Error linking with xerces-c_static_3.lib
In-Reply-To: <788d01cf3964425ea52ffdf204f35e81@nasanexm02h.na.qualcomm.com>
References: <788d01cf3964425ea52ffdf204f35e81@nasanexm02h.na.qualcomm.com>
Message-ID: <boris.20150310140603@codesynthesis.com>

Hi Dave,

Mckinney, Dave <davem@qti.qualcomm.com> writes:

> Did you find a solution for your xerces static linking problem?

Yes, apparently he has[1]:

http://codesynthesis.com/pipermail/xsd-users/2013-December/004161.html


[1] http://codesynthesis.com/pipermail/xsd-users/2013-December/004163.html

Boris

From boris at codesynthesis.com  Tue Mar 10 11:36:03 2015
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Mar 10 11:46:34 2015
Subject: [xsd-users] Re: Serializer prints xmlns attribute of new
	elements after emitting thousands of them
In-Reply-To: <alpine.DEB.2.10.1503091241080.7237@work>
References: <1F897018A4B45549AE2FE45B2DFF9E3A9F6BD0@EX-TT-AC-01.traveltainment.int>
	<alpine.DEB.2.10.1503091241080.7237@work>
Message-ID: <boris.20150310171452@codesynthesis.com>

Hi Yury,

Yury Zaytsev <yury.zaytsev@traveltainment.de> writes:

> It looks like I've managed to reproduce this surprising behavior by making 
> minor modifications to the standard streaming example shipped with the 
> latest version of XSD; please find the diff showing the necessary changes, 
> as well as a sample output attached. I've added the loop only to emit a 
> just a bit over the required magic number of elements; on my machine the 
> threshold seems to be ~500 items.

Thanks for the test case! I've managed to reproduce the problem and
did some digging. The problem is with the clearing of the DOM document
(as it happens, after every 500 elements) in order to force the release
of memory. Here is the background:

Xerces-C++ DOM tries to re-use memory blocks that were allocated and
released in the same document but it doesn't do it for every kind of
block. As a result, the memory used by the document will keep growing
if you keep allocating and deallocating elements, which is exactly
what we do in the streaming serializer. To work around this the
serializer frees the document and allocates a new one after every
500 element create/release cycles.

The problem is, the Xerces-C++ serializer stores shallow copies of
strings when it builds the namespace map during serialization. If
we re-create the document mid-serialization, all the entries in
this map become invalid since they are from the string pool of the
old document. That's the reason for those spurious xml namespace
declarations.

So far, the best way to fix this that I can think of is to re-create
the namespace map when we are re-creating the document. But I am
going to think a bit more to see if there is a better way.

Boris

From davem at qti.qualcomm.com  Tue Mar 10 12:56:35 2015
From: davem at qti.qualcomm.com (Mckinney, Dave)
Date: Wed Mar 11 08:12:44 2015
Subject: [xsd-users] Error linking with xerces-c_static_3.lib
In-Reply-To: <boris.20150310140603@codesynthesis.com>
References: <788d01cf3964425ea52ffdf204f35e81@nasanexm02h.na.qualcomm.com>
	<boris.20150310140603@codesynthesis.com>
Message-ID: <b6fa67421df54c5f807dc16ba186ca12@nasanexm02h.na.qualcomm.com>

Hello,
Yes, thanks for getting back to me. At first I only saw the question, so I wrote the email, but later found the answer. It works great now.

Regards,
Dave

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Tuesday, March 10, 2015 5:07 AM
To: Mckinney, Dave
Cc: xsd-users@codesynthesis.com
Subject: Re: [xsd-users] Error linking with xerces-c_static_3.lib

Hi Dave,

Mckinney, Dave <davem@qti.qualcomm.com> writes:

> Did you find a solution for your xerces static linking problem?

Yes, apparently he has[1]:

http://codesynthesis.com/pipermail/xsd-users/2013-December/004161.html


[1] http://codesynthesis.com/pipermail/xsd-users/2013-December/004163.html

Boris

From yury.zaytsev at traveltainment.de  Wed Mar 11 06:15:07 2015
From: yury.zaytsev at traveltainment.de (Yury Zaytsev)
Date: Wed Mar 11 08:12:44 2015
Subject: [xsd-users] Mapping for string-based enumerations: string
	constructors?
Message-ID: <alpine.DEB.2.10.1503111039210.2048@work>

Hi,

I've noticed that in the C++/Tree generated bindings, string-based 
enumerations have additional constructors that allow users to specify 
arbitrary strings, bypassing the restrictions imposed by the schema.

According to the documentation [*] this is an expected behavior; I 
understand how a string constructor could be useful, but I'm not quite 
sure of what's the use case for allowing arbitrary strings?

[*]: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.6.2

Is there any built-in facility to easily disable these additional 
constructors, or make them reject strings that aren't part of the enum?

I've checked the examples which show how to customize the mappings, but it 
looks rather scary. Instead, I would be happier to maintain a patch 
against XSD, especially if this can be eventually included in the official 
version in the future.

Any thoughts?

-- 
Dr. Yury V. Zaytsev
Senior Software Developer
IT Data Production

TravelTainment GmbH
Carlo-Schmid-Stra?e 12
52146 W?rselen/Aachen, Germany
yury.zaytsev@traveltainment.de

http://www.traveltainment.de

Amtsgericht Aachen, HRB 15873
Gesch?ftsf?hrer: Bernhard Steffens (Vorsitzender),
Dr. Oliver Rengelshausen

From yury.zaytsev at traveltainment.de  Wed Mar 11 06:34:44 2015
From: yury.zaytsev at traveltainment.de (Yury Zaytsev)
Date: Wed Mar 11 08:12:44 2015
Subject: [xsd-users] Re: Serializer prints xmlns attribute of new
	elements after emitting thousands of them
In-Reply-To: <boris.20150310171452@codesynthesis.com>
References: <1F897018A4B45549AE2FE45B2DFF9E3A9F6BD0@EX-TT-AC-01.traveltainment.int>
	<alpine.DEB.2.10.1503091241080.7237@work>
	<boris.20150310171452@codesynthesis.com>
Message-ID: <alpine.DEB.2.10.1503111118530.2048@work>

Hi Boris,

On Tue, 10 Mar 2015, Boris Kolpackov wrote:
>
> So far, the best way to fix this that I can think of is to re-create
> the namespace map when we are re-creating the document. But I am
> going to think a bit more to see if there is a better way.

Thank you very much for investigating the problem and providing this 
detailed clarification!

I'd appreciate if you could let me know once you come up with a solution, 
so that I can pull the patch from your git into my project.

All the best,

-- 
Dr. Yury V. Zaytsev
Senior Software Developer
IT Data Production

TravelTainment GmbH
Carlo-Schmid-Stra?e 12
52146 W?rselen/Aachen, Germany
yury.zaytsev@traveltainment.de

http://www.traveltainment.de

Amtsgericht Aachen, HRB 15873
Gesch?ftsf?hrer: Bernhard Steffens (Vorsitzender),
Dr. Oliver Rengelshausen

From boris at codesynthesis.com  Wed Mar 11 09:01:46 2015
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Mar 11 09:12:16 2015
Subject: [xsd-users] Mapping for string-based enumerations: string
	constructors?
In-Reply-To: <alpine.DEB.2.10.1503111039210.2048@work>
References: <alpine.DEB.2.10.1503111039210.2048@work>
Message-ID: <boris.20150311145245@codesynthesis.com>

Hi Yury,

Yury Zaytsev <yury.zaytsev@traveltainment.de> writes:

> I'm not quite sure of what's the use case for allowing arbitrary
> strings?

There is no use-case. It is that dis-allowing them, in the general
case, is not as straightforward as one may think.

Firstly, this is a programming error that will only be detected
at runtime. Already bad news. There will be a performance
penalty. Things get even worse once you consider inheritance of
enumerations (yes, those things can inherit). Without some
special double-check avoidance mechanism, this will be double
(or triple, for two levels of inheritance, etc) performance
penalty. So, overall, I don't consider this worth the extra
complexity.

The only solution that I am willing to entertain is an option
that will disable the generation of these additional c-tors
(but watch out for default attribute value initialization).

Boris

From boris at codesynthesis.com  Wed Mar 11 09:38:11 2015
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Mar 11 09:48:40 2015
Subject: [xsd-users] Re: Serializer prints xmlns attribute of new
	elements after emitting thousands of them
In-Reply-To: <alpine.DEB.2.10.1503111118530.2048@work>
References: <1F897018A4B45549AE2FE45B2DFF9E3A9F6BD0@EX-TT-AC-01.traveltainment.int>
	<alpine.DEB.2.10.1503091241080.7237@work>
	<boris.20150310171452@codesynthesis.com>
	<alpine.DEB.2.10.1503111118530.2048@work>
Message-ID: <boris.20150311153703@codesynthesis.com>

Hi Yury,

Yury Zaytsev <yury.zaytsev@traveltainment.de> writes:

> I'd appreciate if you could let me know once you come up with a solution, 
> so that I can pull the patch from your git into my project.

Here you go:

http://scm.codesynthesis.com/?p=xsd/xsd.git;a=commit;h=939d5ad2a285a42819a39f7155ed3f672014d4ed

Let me know if you run into any issues with this fix.

Boris

From yury.zaytsev at traveltainment.de  Wed Mar 11 09:48:28 2015
From: yury.zaytsev at traveltainment.de (Yury Zaytsev)
Date: Wed Mar 11 09:54:44 2015
Subject: [xsd-users] Mapping for string-based enumerations: string
	constructors?
In-Reply-To: <boris.20150311145245@codesynthesis.com>
References: <alpine.DEB.2.10.1503111039210.2048@work>
	<boris.20150311145245@codesynthesis.com>
Message-ID: <alpine.DEB.2.10.1503111416240.2048@work>

Hi Boris,

On Wed, 11 Mar 2015, Boris Kolpackov wrote:

> Firstly, this is a programming error that will only be detected
> at runtime. Already bad news. There will be a performance
> penalty. Things get even worse once you consider inheritance of
> enumerations (yes, those things can inherit). Without some
> special double-check avoidance mechanism, this will be double
> (or triple, for two levels of inheritance, etc) performance
> penalty. So, overall, I don't consider this worth the extra
> complexity.

Thank you for the explanation! I concur with your analysis; indeed, it 
seems that adding an extra layer of checks isn't really worth it for the 
common use cases.

> The only solution that I am willing to entertain is an option
> that will disable the generation of these additional c-tors
> (but watch out for default attribute value initialization).

That should certainly work for my purposes, as I currently see no need to 
initialize the enum types e.g. with an empty string in my code, but 
conversely, it will catch invalid initializations at compile time.

However, at the same time it would be useful to have a public conversion 
function (string -> value) in conjunction with the option to disable 
string constructors.

For instance, I currently have dynamic translation tables stored as 
strings in the input files. I could then explicitly call

     EnumType::value v = EnumType::convert("key");
     const auto e = EnumType{v};

and be sure that if "key" (which comes from the translation table that I 
don't control) is not in the schema definition, the conversion will throw 
an exception at runtime.

I'm not sure how high this is going to be on your priorities list (I guess 
not very high ;-) ), but I can try to see if I can have a look into it in 
my spare time before you get to it, if you could point me to the entry 
points in the XSD source code where I'd have to make changes...

P.S. The XSD documentation is excellent, it takes some experience with the 
tool to really understand it, but now I'm really enjoying it.

All the best,

-- 
Dr. Yury V. Zaytsev
Senior Software Developer
IT Data Production

TravelTainment GmbH
Carlo-Schmid-Stra?e 12
52146 W?rselen/Aachen, Germany
yury.zaytsev@traveltainment.de

http://www.traveltainment.de

Amtsgericht Aachen, HRB 15873
Gesch?ftsf?hrer: Bernhard Steffens (Vorsitzender),
Dr. Oliver Rengelshausen

From yury.zaytsev at traveltainment.de  Wed Mar 11 09:59:26 2015
From: yury.zaytsev at traveltainment.de (Yury Zaytsev)
Date: Wed Mar 11 10:05:36 2015
Subject: [xsd-users] Re: Serializer prints xmlns attribute of new
	elements after emitting thousands of them
In-Reply-To: <boris.20150311153703@codesynthesis.com>
References: <1F897018A4B45549AE2FE45B2DFF9E3A9F6BD0@EX-TT-AC-01.traveltainment.int>
	<alpine.DEB.2.10.1503091241080.7237@work>
	<boris.20150310171452@codesynthesis.com>
	<alpine.DEB.2.10.1503111118530.2048@work>
	<boris.20150311153703@codesynthesis.com>
Message-ID: <alpine.DEB.2.10.1503111456020.2048@work>

Hi Boris,

On Wed, 11 Mar 2015, Boris Kolpackov wrote:

> Let me know if you run into any issues with this fix.

Thank you very much!

I've just tested it on some ~20 000 elements and the redundant xmlns 
attributes have indeed disappeared. Additionally, I wasn't able to 
identify any other differences in the output, so, hopefully, it didn't 
cause any regressions either :-)

All the best,

-- 
Dr. Yury V. Zaytsev
Senior Software Developer
IT Data Production

TravelTainment GmbH
Carlo-Schmid-Stra?e 12
52146 W?rselen/Aachen, Germany
yury.zaytsev@traveltainment.de

http://www.traveltainment.de

Amtsgericht Aachen, HRB 15873
Gesch?ftsf?hrer: Bernhard Steffens (Vorsitzender),
Dr. Oliver Rengelshausen

From boris at codesynthesis.com  Thu Mar 12 09:58:49 2015
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Mar 12 10:09:20 2015
Subject: [xsd-users] Mapping for string-based enumerations: string
	constructors?
In-Reply-To: <alpine.DEB.2.10.1503111416240.2048@work>
References: <alpine.DEB.2.10.1503111039210.2048@work>
	<boris.20150311145245@codesynthesis.com>
	<alpine.DEB.2.10.1503111416240.2048@work>
Message-ID: <boris.20150312155219@codesynthesis.com>

Hi Yury,

Yury Zaytsev <yury.zaytsev@traveltainment.de> writes:

> However, at the same time it would be useful to have a public conversion 
> function (string -> value) in conjunction with the option to disable 
> string constructors.

Here we go... As I said, the only "fix" that I am willing to entertain
is to disable the string-based ctors. Nothing extra.


> For instance, I currently have dynamic translation tables stored as 
> strings in the input files. I could then explicitly call
> 
>      EnumType::value v = EnumType::convert("key");
>      const auto e = EnumType{v};

You know you can use type customization with a template to wrap all
your generated enums and provide exactly the interface that you need?


Boris

From maxim.maslennikov at gmail.com  Thu Mar 12 16:13:07 2015
From: maxim.maslennikov at gmail.com (Maxim Maslennikov)
Date: Fri Mar 13 09:07:56 2015
Subject: [xsd-users] XSD uses a lot of memory
In-Reply-To: <boris.20150310140242@codesynthesis.com>
References: <FB747C77-3109-473C-B7BC-D9633D741E86@gmail.com>
	<boris.20150303130956@codesynthesis.com>
	<B7854BD0-3F79-4328-8DC1-A6CE951FEF78@gmail.com>
	<boris.20150310140242@codesynthesis.com>
Message-ID: <40FED112-32D2-4788-ADCB-214CBAF9C941@gmail.com>

Boris,

Enclosed are sources of the program based on libstudxml and xsd file.

The xsd program and xsd file are below:
#include <iostream>
#include <chrono>

#include "test.hxx"

using namespace std;

int main(int argc, const char * argv[]) {
    if (argc != 2)
    {
        cerr << "usage: " << argv[0] << " test.xml" << endl;
        return 1;
    }
    
    try
    {
        auto t = chrono::steady_clock::now();
        
        // Parsing and Binding
        unique_ptr<test::root> root (test::root_ (argv[1]));
        
        cerr << "Number of elements: " << root->record().size() << endl;
        cerr << "Binding Duration: " << chrono::duration_cast<chrono::milliseconds>(chrono::steady_clock::now()-t).count() << " ms\n?;
       
        // Serialize the modified object model to XML.
        //
        xml_schema::namespace_infomap map;
        map[""].name = "";
        map[""].schema = "test.xsd";
        
        t = chrono::steady_clock::now();
        
        test::root_ (cout, *root, map);
        
        cerr << "Serializing Duration: " << chrono::duration_cast<chrono::milliseconds>(chrono::steady_clock::now()-t).count() << " ms\n";
        
    }
    catch (const xml_schema::exception& e)
    {
        cerr << e << endl;
        return 1;
    }

}


To test the programs I generated a test file by gen program from libstudxml examples about 100Mb size.

Best Regards,
Maxim

> On Mar 10, 2015, at 3:05 PM, Boris Kolpackov <boris@codesynthesis.com> wrote:
> 
> Hi Maxim,
> 
> Maxim Maslennikov <maxim.maslennikov@gmail.com> writes:
> 
>> I meant my program uses an "object persistance" approach described
>> in your document - "XML Parsing and Serialization in C++ With
>> libstudxml? and also saves all data in memory.
> 
> You mean the data for the *entire* document is stored in memory?
> 
> 
>> So my question is why does xsd C++/tree use about ten time more
>> memory? I found it when generated a file of records about 100Mb
>> size.
> 
> If the answer to the above question is "yes", then I will need to
> see a test that reproduces this. C++/Tree definitely shouldn't
> use 10 times more memory.
> 
> Boris

From tsroynciitraoln at gmail.com  Mon Mar 16 05:08:51 2015
From: tsroynciitraoln at gmail.com (tsroynciitraoln)
Date: Mon Mar 16 09:22:52 2015
Subject: [xsd-users] Bug ?
Message-ID: <CAM5cvC25eupfQTqgPeiQ+j_61tQK-ND42dxVLxdLfk0Nj=EPzw@mail.gmail.com>

Hi,

I noticed a strange behavior using XSD. I will explain you how to reproduce
the issue.

    - Consider this projet:
http://sourceforge.net/projects/openadrvenclibrary/, go in "schema/2b"
    - Download CodeSynthesis XSD 4.0 for Mac, and execute the "build.sh"
script -> all is ok !
    - Do exactly the same on Windows 8.1 x64 (with CodeSynthesis XSD 4.0)
and you will got an issue (see cli dump in attachement)

Why the result is different ?

Best regards
-------------- next part --------------
Microsoft Windows [version 6.3.9600]
(c) 2013 Microsoft Corporation. Tous droits r?serv?s.

oadr_xcal_20b.xsd:84:51: warning F001: element 'components' is implicitly of any
Type
oadr_xcal_20b.xsd:84:51: info: did you forget to specify 'type' attribute?
oadr_greenbutton.xsd:723:56: warning F001: element 'denominator' is implicitly o
f anyType
oadr_greenbutton.xsd:723:56: info: did you forget to specify 'type' attribute?
oadr_greenbutton.xsd:732:56: warning F001: element 'denominator' is implicitly o
f anyType
oadr_greenbutton.xsd:732:56: info: did you forget to specify 'type' attribute?
oadr_20b.xsd: warning T004: generating parsing and serialization functions for 6
2 global elements
oadr_20b.xsd: info: use --root-element-* options to specify document root(s)
oadr_atom.xsd: warning T004: generating parsing and serialization functions for
2 global elements
oadr_atom.xsd: info: use --root-element-* options to specify document root(s)
oadr_ei_20b.xsd:10:70: error: global element 'eventStatus' declared more than on
ce
oadr_ei_20b.xsd:12:50: error: global type 'simpleType:EventStatusEnumeratedType'
 declared more than once or also declared as complexType
oadr_ei_20b.xsd:47:50: error: global element 'resourceID' declared more than onc
e
oadr_ei_20b.xsd:49:47: error: global element 'groupID' declared more than once
oadr_ei_20b.xsd:51:47: error: global element 'partyID' declared more than once
oadr_ei_20b.xsd:53:49: error: global element 'groupName' declared more than once

oadr_ei_20b.xsd:54:45: error: global type 'simpleType:EiExtensionTokenType' decl
ared more than once or also declared as complexType
oadr_ei_20b.xsd:63:45: error: global element 'venID' declared more than once
oadr_ei_20b.xsd:65:45: error: global element 'vtnID' declared more than once
oadr_ei_20b.xsd:67:46: error: global element 'eventID' declared more than once
oadr_ei_20b.xsd:73:62: error: global element 'modificationNumber' declared more
than once
oadr_ei_20b.xsd:79:70: error: global element 'qualifiedEventID' declared more th
an once
oadr_ei_20b.xsd:81:46: error: global type 'complexType:QualifiedEventIDType' dec
lared more than once or also declared as simpleType
oadr_ei_20b.xsd:91:67: error: global element 'x-eiNotification' declared more th
an once
oadr_ei_20b.xsd:97:61: error: global element 'x-eiRampUp' declared more than onc
e
oadr_ei_20b.xsd:103:63: error: global element 'x-eiRecovery' declared more than
once
oadr_ei_20b.xsd:109:54: error: global element 'interval' declared more than once

oadr_ei_20b.xsd:110:38: error: global type 'complexType:IntervalType' declared m
ore than once or also declared as simpleType
oadr_ei_20b.xsd:119:61: error: global element 'currentValue' declared more than
once
oadr_ei_20b.xsd:124:42: error: global type 'complexType:currentValueType' declar
ed more than once or also declared as simpleType
oadr_ei_20b.xsd:130:76: error: global element 'payloadBase' declared more than o
nce
oadr_ei_20b.xsd:131:57: error: global type 'complexType:PayloadBaseType' declare
d more than once or also declared as simpleType
oadr_ei_20b.xsd:136:96: error: global element 'payloadFloat' declared more than
once
oadr_ei_20b.xsd:141:42: error: global type 'complexType:PayloadFloatType' declar
ed more than once or also declared as simpleType
oadr_ei_20b.xsd:155:61: error: global element 'responseCode' declared more than
once
oadr_ei_20b.xsd:161:41: error: global type 'simpleType:ResponseCodeType' declare
d more than once or also declared as complexType
oadr_ei_20b.xsd:177:58: error: global element 'responseDescription' declared mor
e than once
oadr_ei_20b.xsd:183:51: error: global element 'optType' declared more than once
oadr_ei_20b.xsd:188:36: error: global type 'simpleType:OptTypeType' declared mor
e than once or also declared as complexType
oadr_ei_20b.xsd:195:57: error: global element 'eiResponse' declared more than on
ce
oadr_ei_20b.xsd:200:40: error: global type 'complexType:EiResponseType' declared
 more than once or also declared as simpleType
oadr_ei_20b.xsd:208:36: error: global element 'eventResponses' declared more tha
n once
oadr_ei_20b.xsd:230:52: error: global element 'eiEvent' declared more than once
oadr_ei_20b.xsd:231:37: error: global type 'complexType:eiEventType' declared mo
re than once or also declared as simpleType
oadr_ei_20b.xsd:240:65: error: global element 'eiActivePeriod' declared more tha
n once
oadr_ei_20b.xsd:245:44: error: global type 'complexType:eiActivePeriodType' decl
ared more than once or also declared as simpleType
oadr_ei_20b.xsd:252:67: error: global element 'signalType' declared more than on
ce
oadr_ei_20b.xsd:258:49: error: global type 'simpleType:SignalTypeEnumeratedType'
 declared more than once or also declared as complexType
oadr_ei_20b.xsd:322:59: error: global element 'responses' declared more than onc
e
oadr_ei_20b.xsd:323:42: error: global type 'complexType:ArrayofResponses' declar
ed more than once or also declared as simpleType
oadr_ei_20b.xsd:332:67: error: global element 'eventDescriptor' declared more th
an once
oadr_ei_20b.xsd:337:45: error: global type 'complexType:eventDescriptorType' dec
lared more than once or also declared as simpleType
oadr_ei_20b.xsd:381:106: error: global element 'signalPayload' declared more tha
n once
oadr_ei_20b.xsd:386:43: error: global type 'complexType:signalPayloadType' decla
red more than once or also declared as simpleType
oadr_ei_20b.xsd:396:62: error: global element 'createdDateTime' declared more th
an once
oadr_ei_20b.xsd:402:53: error: global element 'eiTarget' declared more than once

oadr_ei_20b.xsd:407:38: error: global type 'complexType:EiTargetType' declared m
ore than once or also declared as simpleType
oadr_ei_20b.xsd:425:64: error: global element 'eiEventSignal' declared more than
 once
oadr_ei_20b.xsd:426:43: error: global type 'complexType:eiEventSignalType' decla
red more than once or also declared as simpleType
oadr_ei_20b.xsd:453:58: error: global element 'signalName' declared more than on
ce
oadr_ei_20b.xsd:454:39: error: global type 'simpleType:signalNameType' declared
more than once or also declared as complexType
oadr_ei_20b.xsd:460:78: error: global element 'SignalNameEnumerated' declared mo
re than once
oadr_ei_20b.xsd:461:49: error: global type 'simpleType:SignalNameEnumeratedType'
 declared more than once or also declared as complexType
oadr_ei_20b.xsd:521:65: error: global element 'eiEventSignals' declared more tha
n once
oadr_ei_20b.xsd:526:44: error: global type 'complexType:eiEventSignalsType' decl
ared more than once or also declared as simpleType
oadr_ei_20b.xsd:541:67: error: global element 'eiEventBaseline' declared more th
an once
oadr_ei_20b.xsd:546:45: error: global type 'complexType:eiEventBaselineType' dec
lared more than once or also declared as simpleType
oadr_ei_20b.xsd:571:35: error: global type 'complexType:EiOptType' declared more
 than once or also declared as simpleType
oadr_ei_20b.xsd:587:55: error: global element 'optReason' declared more than onc
e
oadr_ei_20b.xsd:592:38: error: global type 'simpleType:OptReasonType' declared m
ore than once or also declared as complexType
oadr_ei_20b.xsd:598:76: error: global element 'optReasonEnumerated' declared mor
e than once
oadr_ei_20b.xsd:599:48: error: global type 'simpleType:OptReasonEnumeratedType'
declared more than once or also declared as complexType
oadr_ei_20b.xsd:615:44: error: global element 'optID' declared more than once
oadr_ei_20b.xsd:621:49: error: global element 'eiReportID' declared more than on
ce
oadr_ei_20b.xsd:626:54: error: global element 'reportRequestID' declared more th
an once
oadr_ei_20b.xsd:631:56: error: global element 'reportSpecifierID' declared more
than once
oadr_ei_20b.xsd:636:57: error: global element 'reportName' declared more than on
ce
oadr_ei_20b.xsd:641:39: error: global type 'simpleType:reportNameType' declared
more than once or also declared as complexType
oadr_ei_20b.xsd:644:49: error: global type 'simpleType:reportNameEnumeratedType'
 declared more than once or also declared as complexType
oadr_ei_20b.xsd:656:42: error: global element 'rID' declared more than once
oadr_ei_20b.xsd:661:58: error: global element 'reportSubject' declared more than
 once
oadr_ei_20b.xsd:666:61: error: global element 'reportDataSource' declared more t
han once
oadr_ei_20b.xsd:671:61: error: global element 'statusDateTime' declared more tha
n once
oadr_ei_20b.xsd:676:58: error: global element 'reportType' declared more than on
ce
oadr_ei_20b.xsd:677:39: error: global type 'simpleType:ReportTypeType' declared
more than once or also declared as complexType
oadr_ei_20b.xsd:683:70: error: global element 'reportEnumerated' declared more t
han once
oadr_ei_20b.xsd:684:45: error: global type 'simpleType:ReportEnumeratedType' dec
lared more than once or also declared as complexType
oadr_ei_20b.xsd:811:59: error: global element 'readingType' declared more than o
nce
oadr_ei_20b.xsd:816:40: error: global type 'simpleType:ReadingTypeType' declared
 more than once or also declared as complexType
oadr_ei_20b.xsd:822:80: error: global element 'readingTypeEnumerated' declared m
ore than once
oadr_ei_20b.xsd:823:50: error: global type 'simpleType:ReadingTypeEnumeratedType
' declared more than once or also declared as complexType
oadr_ei_20b.xsd:892:58: error: global element 'confidence' declared more than on
ce
oadr_ei_20b.xsd:893:39: error: global type 'simpleType:ConfidenceType' declared
more than once or also declared as complexType
oadr_ei_20b.xsd:899:54: error: global element 'accuracy' declared more than once

oadr_ei_20b.xsd:900:37: error: global type 'simpleType:AccuracyType' declared mo
re than once or also declared as complexType
oadr_ei_20b.xsd:907:43: error: global type 'complexType:ReportPayloadType' decla
red more than once or also declared as simpleType
oadr_ei_20b.xsd:934:59: error: global element 'numDataSources' declared more tha
n once
oadr_ei_20b.xsd:936:67: error: global element 'reportSpecifier' declared more th
an once
oadr_ei_20b.xsd:941:45: error: global type 'complexType:ReportSpecifierType' dec
lared more than once or also declared as simpleType
oadr_ei_20b.xsd:966:70: error: global element 'specifierPayload' declared more t
han once
oadr_ei_20b.xsd:967:46: error: global type 'complexType:SpecifierPayloadType' de
clared more than once or also declared as simpleType
oadr_ei_20b.xsd:982:54: error: global element 'registrationID' declared more tha
n once
oadr_ei_20b.xsd:988:54: error: global element 'refID' declared more than once
oadr_ei_20b.xsd:994:60: error: global element 'uid' declared more than once
oadr_ei_20b.xsd:995:32: error: global type 'simpleType:UidType' declared more th
an once or also declared as complexType
oadr_ei_20b.xsd:1002:66: error: attribute 'schemaVersion' declared more than onc
e in the same scope
oadr_ei_20b.xsd:1003:42: error: global type 'simpleType:schemaVersionType' decla
red more than once or also declared as complexType
oadr_ei_20b.xsd:1006:52: error: global type 'simpleType:schemaVersionEnumeratedT
ype' declared more than once or also declared as complexType

C:\Users\Satin\Desktop\2b>
From boris at codesynthesis.com  Mon Mar 16 09:39:44 2015
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Mar 16 09:50:14 2015
Subject: [xsd-users] Bug ?
In-Reply-To: <CAM5cvC25eupfQTqgPeiQ+j_61tQK-ND42dxVLxdLfk0Nj=EPzw@mail.gmail.com>
References: <CAM5cvC25eupfQTqgPeiQ+j_61tQK-ND42dxVLxdLfk0Nj=EPzw@mail.gmail.com>
Message-ID: <boris.20150316153757@codesynthesis.com>

Hi,

tsroynciitraoln <tsroynciitraoln@gmail.com> writes:

> Why the result is different?

Most likely it has something to do with case-insensitive paths. There
was one bug fixed in XSD 4.0.0 that is related to this issue. Could
you try the following pre-release and see if you get the same result:

http://codesynthesis.com/~boris/tmp/xsd/xsd-4.1.0.a3-i686-windows.zip

Boris

From boris at codesynthesis.com  Mon Mar 16 09:45:33 2015
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Mar 16 09:56:02 2015
Subject: [xsd-users] XSD uses a lot of memory
In-Reply-To: <40FED112-32D2-4788-ADCB-214CBAF9C941@gmail.com>
References: <FB747C77-3109-473C-B7BC-D9633D741E86@gmail.com>
	<boris.20150303130956@codesynthesis.com>
	<B7854BD0-3F79-4328-8DC1-A6CE951FEF78@gmail.com>
	<boris.20150310140242@codesynthesis.com>
	<40FED112-32D2-4788-ADCB-214CBAF9C941@gmail.com>
Message-ID: <boris.20150316154140@codesynthesis.com>

Hi Maxim,

Maxim Maslennikov <maxim.maslennikov@gmail.com> writes:

> Enclosed are sources of the program based on libstudxml and xsd file.

I don't see the source for the program based on libstudxml? If
you are using the unmodified 'performance' example, then that
implementation doesn't store a single bit of the object model
in memory. In fact, the parser is configured to the limits not
to store anything in memory. It would be hard to find a more
obvious "apples to oranged" comparison.

Boris

From maxim.maslennikov at gmail.com  Mon Mar 16 17:39:57 2015
From: maxim.maslennikov at gmail.com (Maxim Maslennikov)
Date: Tue Mar 17 06:25:38 2015
Subject: [xsd-users] XSD uses a lot of memory
In-Reply-To: <boris.20150316154140@codesynthesis.com>
References: <FB747C77-3109-473C-B7BC-D9633D741E86@gmail.com>
	<boris.20150303130956@codesynthesis.com>
	<B7854BD0-3F79-4328-8DC1-A6CE951FEF78@gmail.com>
	<boris.20150310140242@codesynthesis.com>
	<40FED112-32D2-4788-ADCB-214CBAF9C941@gmail.com>
	<boris.20150316154140@codesynthesis.com>
Message-ID: <2B4253A9-E358-43E8-A609-C2D4683B4A12@gmail.com>

Hi Boris,

I used ?persistence? example modified it to parse and serialize xml with scheme described in test.xsd.
A root object saves all record object in std::vector as you can see in record.cpp.
 
I builded an executable file as:
	clang -std=c++11 -O2 record.cpp main.cpp -lstudxml -o driver.
Next I generate a test xml file of 635k records by program gen from 'performance' example.
And run as:
	./driver test-100m.xml > /dev/null.
The driver took about 142Mb memory according top output.
XSD example which I sent in previous mail took about 800Mb memory.

I again attached the files.



Thanks in advance,
Maxim


> On Mar 16, 2015, at 4:45 PM, Boris Kolpackov <boris@codesynthesis.com> wrote:
> 
> Hi Maxim,
> 
> Maxim Maslennikov <maxim.maslennikov@gmail.com> writes:
> 
>> Enclosed are sources of the program based on libstudxml and xsd file.
> 
> I don't see the source for the program based on libstudxml? If
> you are using the unmodified 'performance' example, then that
> implementation doesn't store a single bit of the object model
> in memory. In fact, the parser is configured to the limits not
> to store anything in memory. It would be hard to find a more
> obvious "apples to oranged" comparison.
> 
> Boris

From boris at codesynthesis.com  Tue Mar 17 07:01:53 2015
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Mar 17 07:12:24 2015
Subject: [xsd-users] XSD uses a lot of memory
In-Reply-To: <2B4253A9-E358-43E8-A609-C2D4683B4A12@gmail.com>
References: <FB747C77-3109-473C-B7BC-D9633D741E86@gmail.com>
	<boris.20150303130956@codesynthesis.com>
	<B7854BD0-3F79-4328-8DC1-A6CE951FEF78@gmail.com>
	<boris.20150310140242@codesynthesis.com>
	<40FED112-32D2-4788-ADCB-214CBAF9C941@gmail.com>
	<boris.20150316154140@codesynthesis.com>
	<2B4253A9-E358-43E8-A609-C2D4683B4A12@gmail.com>
Message-ID: <boris.20150317125320@codesynthesis.com>

Hi Maxim,

Maxim Maslennikov <maxim.maslennikov@gmail.com> writes:

> I again attached the files.

The mailing list software strips your attachments for some reason.

In any case, I got them, so let's see:

1. XSD stores string-based enums as both strings and C++ enums
   (that's the "requirement", so to speak, of XML Schema). You
   store them as C++ enums only.

2. There are 4 choice elements for which XSD has separate
   data members while you have one member (imagine they were
   all of different types).

3. XSD, in order to support things like polymorphism, stores
   elements as separately-allocated nodes (unless they are of
   C++ fundamental types) while your object model does it by-
   value.

The bottom line is this: you will always be able to produce
much more efficient and optimized object model by hand since
you can make all kinds of situation-specific assumptions that
XSD can't.

Also, another thing that you can try is XSD/e and its C++/Hybrid
mapping. I am pretty sure it will be a lot closer to your object
model since it doesn't try to be as flexible and "dynamic" as
XSD.

Boris

From tsroynciitraoln at gmail.com  Tue Mar 17 08:44:25 2015
From: tsroynciitraoln at gmail.com (tsroynciitraoln)
Date: Wed Mar 18 05:49:15 2015
Subject: [xsd-users] Bug ?
In-Reply-To: <boris.20150316153757@codesynthesis.com>
References: <CAM5cvC25eupfQTqgPeiQ+j_61tQK-ND42dxVLxdLfk0Nj=EPzw@mail.gmail.com>
	<boris.20150316153757@codesynthesis.com>
Message-ID: <CAM5cvC3=UOJxUWoytW2ufGQx-XCCcJN4R1FiBGjyyFwP-Wio+Q@mail.gmail.com>

Hi,

its working with this new version... but I found another issue. Again with
the same project, file generation is fine with or without the use of the
"--file-per-type" option. The problem is when compiling with Visual Studio
(2013), if the "--file-per-type" isn't used, errors occurs (all is fine
when "--file-per-type" is used !):

    - error C2504: 'stream::StreamPayloadBaseType' : classe de base non
d?finie
    - error C2504: 'stream::StreamPayloadBaseType' : classe de base non
d?finie
    - a lot of another errors...

Best regards

2015-03-16 14:39 GMT+01:00 Boris Kolpackov <boris@codesynthesis.com>:

> Hi,
>
> tsroynciitraoln <tsroynciitraoln@gmail.com> writes:
>
> > Why the result is different?
>
> Most likely it has something to do with case-insensitive paths. There
> was one bug fixed in XSD 4.0.0 that is related to this issue. Could
> you try the following pre-release and see if you get the same result:
>
> http://codesynthesis.com/~boris/tmp/xsd/xsd-4.1.0.a3-i686-windows.zip
>
> Boris
>
From boris at codesynthesis.com  Wed Mar 18 08:52:35 2015
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Wed Mar 18 09:03:04 2015
Subject: [xsd-users] Bug ?
In-Reply-To: <CAM5cvC3=UOJxUWoytW2ufGQx-XCCcJN4R1FiBGjyyFwP-Wio+Q@mail.gmail.com>
References: <CAM5cvC25eupfQTqgPeiQ+j_61tQK-ND42dxVLxdLfk0Nj=EPzw@mail.gmail.com>
	<boris.20150316153757@codesynthesis.com>
	<CAM5cvC3=UOJxUWoytW2ufGQx-XCCcJN4R1FiBGjyyFwP-Wio+Q@mail.gmail.com>
Message-ID: <boris.20150318144843@codesynthesis.com>

Hi,

tsroynciitraoln <tsroynciitraoln@gmail.com> writes:

> Again with the same project, file generation is fine with or without
> the use of the "--file-per-type" option. The problem is when compiling
> with Visual Studio (2013), if the "--file-per-type" isn't used, errors
> occurs (all is fine when "--file-per-type" is used !):

Well, the reason there is the file-per-type mode is because some
schemas cannot be used in the default file-per-schema mode. I
suggest that you read about the reasons for file-per-type here:

http://www.codesynthesis.com/~boris/blog/2008/02/13/codesynthesis-xsd-3-1-0-released/

Then, hopefully, the errors that you get should make a lot more
sense.

Boris

From maxim.maslennikov at gmail.com  Wed Mar 18 15:16:56 2015
From: maxim.maslennikov at gmail.com (Maxim Maslennikov)
Date: Thu Mar 19 10:08:16 2015
Subject: [xsd-users] XSD uses a lot of memory
In-Reply-To: <boris.20150317125320@codesynthesis.com>
References: <FB747C77-3109-473C-B7BC-D9633D741E86@gmail.com>
	<boris.20150303130956@codesynthesis.com>
	<B7854BD0-3F79-4328-8DC1-A6CE951FEF78@gmail.com>
	<boris.20150310140242@codesynthesis.com>
	<40FED112-32D2-4788-ADCB-214CBAF9C941@gmail.com>
	<boris.20150316154140@codesynthesis.com>
	<2B4253A9-E358-43E8-A609-C2D4683B4A12@gmail.com>
	<boris.20150317125320@codesynthesis.com>
Message-ID: <38819ED6-3122-4542-A2C2-38061324CDDA@gmail.com>

Hi Boris,

Thank you for the clarification.

Best Regards,
Maxim

> On Mar 17, 2015, at 2:01 PM, Boris Kolpackov <boris@codesynthesis.com> wrote:
> 
> Hi Maxim,
> 
> Maxim Maslennikov <maxim.maslennikov@gmail.com> writes:
> 
>> I again attached the files.
> 
> The mailing list software strips your attachments for some reason.
> 
> In any case, I got them, so let's see:
> 
> 1. XSD stores string-based enums as both strings and C++ enums
>   (that's the "requirement", so to speak, of XML Schema). You
>   store them as C++ enums only.
> 
> 2. There are 4 choice elements for which XSD has separate
>   data members while you have one member (imagine they were
>   all of different types).
> 
> 3. XSD, in order to support things like polymorphism, stores
>   elements as separately-allocated nodes (unless they are of
>   C++ fundamental types) while your object model does it by-
>   value.
> 
> The bottom line is this: you will always be able to produce
> much more efficient and optimized object model by hand since
> you can make all kinds of situation-specific assumptions that
> XSD can't.
> 
> Also, another thing that you can try is XSD/e and its C++/Hybrid
> mapping. I am pretty sure it will be a lot closer to your object
> model since it doesn't try to be as flexible and "dynamic" as
> XSD.
> 
> Boris

From yury.zaytsev at traveltainment.de  Thu Mar 19 12:23:38 2015
From: yury.zaytsev at traveltainment.de (Yury Zaytsev)
Date: Fri Mar 20 07:37:43 2015
Subject: [xsd-users] Handling of complex restrictions on types
Message-ID: <alpine.DEB.2.10.1503191701160.7603@work>

Hi,

In relation to my previous posts about enums, I'm now wondering what's the 
general strategy of the generator with respect to complex restrictions on 
types, and string types in particular.

I've had a look at the generated code, and so far was unable to find 
anything that handles them, so is it correct to assume that they are 
simply ignored at the moment, or am I missing something obvious?

In my schemas, I have a lot of restrictions of this kind:

 	<xs:simpleType name="TagNameType">
 		<xs:restriction base="xs:string">
 			<xs:minLength value="1"/>
 			<xs:maxLength value="30"/>
 			<xs:pattern value="[A-Za-z0-9\.\-_|]+"/>
 		</xs:restriction>
 	</xs:simpleType>

Ideally, I would like to have all of them checked at runtime, so that the 
constructors and/or setters would raise an exception when the restrictions 
are not adhered to.

Just to clarify why this is important to me: I expect to be generating the 
XML files of sizes in the rage of hundreds of gigabytes, and at this scale 
they take a very substantial amount of time to fully validate against the 
original schema. Therefore, the earlier I can catch the problems with the 
data, the better...

Potentially, I can re-implement these restrictions manually in the code, 
but on one hand, it's a large amount of work, and, on the other hand, it's 
hardly maintainable, because as soon as the restrictions change in the 
schema, my code immediately gets out of sync with it.

The latter is exactly the situation I was trying to avoid by using an 
automatic data bindings generator... Any thoughts?

Many thanks,

-- 
Dr. Yury V. Zaytsev
Senior Software Developer
IT Data Production

TravelTainment GmbH
Carlo-Schmid-Stra?e 12
52146 W?rselen/Aachen, Germany
yury.zaytsev@traveltainment.de

http://www.traveltainment.de

Amtsgericht Aachen, HRB 15873
Gesch?ftsf?hrer: Bernhard Steffens (Vorsitzender),
Dr. Oliver Rengelshausen

From tsroynciitraoln at gmail.com  Fri Mar 20 04:45:01 2015
From: tsroynciitraoln at gmail.com (tsroynciitraoln)
Date: Fri Mar 20 07:37:43 2015
Subject: [xsd-users] Bug ?
In-Reply-To: <boris.20150318144843@codesynthesis.com>
References: <CAM5cvC25eupfQTqgPeiQ+j_61tQK-ND42dxVLxdLfk0Nj=EPzw@mail.gmail.com>
	<boris.20150316153757@codesynthesis.com>
	<CAM5cvC3=UOJxUWoytW2ufGQx-XCCcJN4R1FiBGjyyFwP-Wio+Q@mail.gmail.com>
	<boris.20150318144843@codesynthesis.com>
Message-ID: <CAM5cvC3XM1TaUzb=tuqV3HLtsKCN+Hv6ZA6eXBJGvEx+5_+z6w@mail.gmail.com>

Hi,

thanks, the article is quite clear on the --file-per-type genesis...

Thanks again for your reactivity
Best regards

2015-03-18 13:52 GMT+01:00 Boris Kolpackov <boris@codesynthesis.com>:

> Hi,
>
> tsroynciitraoln <tsroynciitraoln@gmail.com> writes:
>
> > Again with the same project, file generation is fine with or without
> > the use of the "--file-per-type" option. The problem is when compiling
> > with Visual Studio (2013), if the "--file-per-type" isn't used, errors
> > occurs (all is fine when "--file-per-type" is used !):
>
> Well, the reason there is the file-per-type mode is because some
> schemas cannot be used in the default file-per-schema mode. I
> suggest that you read about the reasons for file-per-type here:
>
>
> http://www.codesynthesis.com/~boris/blog/2008/02/13/codesynthesis-xsd-3-1-0-released/
>
> Then, hopefully, the errors that you get should make a lot more
> sense.
>
> Boris
>
From garry.jeromson at enclustra.com  Fri Mar 20 11:08:03 2015
From: garry.jeromson at enclustra.com (Garry Jeromson)
Date: Fri Mar 20 11:08:14 2015
Subject: [xsd-users] Namspace schema with spaces in the file path
Message-ID: <1520C279C80F2343A5C090E835E4E13DD6C03FB4@CLUSTRAONE.clustra.local>

Hullo,

I'm encountering a classic spaces-in-the-path issue; my application expects some XML files to be in a subfolder relative to the .exe, so I get the full path on the fly at run-time. The schema for said XML has a namespace, which I pass in when parsing as follows:

xml_schema::properties xmlProperties;
xmlProperties.schema_location("EepromMemoryMaps", schemaFilePath);
auto_ptr<EepromXml::EEPROMMemoryMap> pParsedXml(EepromXml::EEPROMMemoryMap_(eepromMapXmlPath, 0, xmlProperties));

When the path to the .exe has spaces in it (as I'd like to have, so it can live in the Program Files folder on Windows), parsing fails because of the spaces. The error "unable to open primary document entity 'C:\path'" is given in the diagnostics; the full path to the files is "C:\path with spaces".

Is there any way to get around this without hacking away at the generated .cxx file?

Cheers,

Garry

From garry.jeromson at enclustra.com  Fri Mar 20 11:58:19 2015
From: garry.jeromson at enclustra.com (Garry Jeromson)
Date: Fri Mar 20 11:58:28 2015
Subject: [xsd-users] RE: Namspace schema with spaces in the file path
In-Reply-To: <1520C279C80F2343A5C090E835E4E13DD6C03FB4@CLUSTRAONE.clustra.local>
References: <1520C279C80F2343A5C090E835E4E13DD6C03FB4@CLUSTRAONE.clustra.local>
Message-ID: <1520C279C80F2343A5C090E835E4E13DD6C03FE4@CLUSTRAONE.clustra.local>

Found the solution via the Xerces forums - paths with spaces need to have the spaces replaced with "%20", and be prefixed with "file:///".

Cheers,

Garry

-----Original Message-----
From: xsd-users-bounces@codesynthesis.com [mailto:xsd-users-bounces@codesynthesis.com] On Behalf Of Garry Jeromson
Sent: Freitag, 20. M?rz 2015 16:08
To: xsd-users@codesynthesis.com
Subject: [xsd-users] Namspace schema with spaces in the file path

Hullo,

I'm encountering a classic spaces-in-the-path issue; my application expects some XML files to be in a subfolder relative to the .exe, so I get the full path on the fly at run-time. The schema for said XML has a namespace, which I pass in when parsing as follows:

xml_schema::properties xmlProperties;
xmlProperties.schema_location("EepromMemoryMaps", schemaFilePath); auto_ptr<EepromXml::EEPROMMemoryMap> pParsedXml(EepromXml::EEPROMMemoryMap_(eepromMapXmlPath, 0, xmlProperties));

When the path to the .exe has spaces in it (as I'd like to have, so it can live in the Program Files folder on Windows), parsing fails because of the spaces. The error "unable to open primary document entity 'C:\path'" is given in the diagnostics; the full path to the files is "C:\path with spaces".

Is there any way to get around this without hacking away at the generated .cxx file?

Cheers,

Garry


From boris at codesynthesis.com  Mon Mar 23 08:14:29 2015
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Mar 23 08:25:56 2015
Subject: [xsd-users] Handling of complex restrictions on types
In-Reply-To: <alpine.DEB.2.10.1503191701160.7603@work>
References: <alpine.DEB.2.10.1503191701160.7603@work>
Message-ID: <boris.20150323140359@codesynthesis.com>

Hi Yury,

Yury Zaytsev <yury.zaytsev@traveltainment.de> writes:

> I've had a look at the generated code, and so far was unable to find 
> anything that handles them, so is it correct to assume that they are 
> simply ignored at the moment, or am I missing something obvious?

Yes, there is no runtime validation of schema constraints. Some
of them are translated to compile-time constraints (for example,
you won't be able to create a type with a required element without
supplying its value). But nothing at runtime.


> Ideally, I would like to have all of them checked at runtime, so that the 
> constructors and/or setters would raise an exception when the restrictions 
> are not adhered to.

While some could argue that this is not the right way to handle it (i.e.,
this is a "programming error", from the object model's point of view), I
can also see why some might want this behavior. The good question to ask
is what are you going to do when such an exception is thrown? In
particular, there is almost certainly no way to automatically recover
from it.


> Potentially, I can re-implement these restrictions manually in the code, 
> but on one hand, it's a large amount of work, and, on the other hand, it's 
> hardly maintainable, because as soon as the restrictions change in the 
> schema, my code immediately gets out of sync with it.

Yes, all valid points. Unfortunately, implementing restriction
validation in the generated code if probably an order of magnitude
larger amount of work. And at this stage we have to plans to
do it.

If you do decide to implement this yourself, you may want to check
the type customization mechanism. This way you will be able to add
the extra checks transparently wrt to the users of the object model.

Boris

From xiaohan at andrew.cmu.edu  Mon Mar 30 10:03:24 2015
From: xiaohan at andrew.cmu.edu (Xiao Han)
Date: Wed Apr  1 06:45:00 2015
Subject: [xsd-users] Can not compile hello example on Mac
Message-ID: <CALD8DcCM7iLhBX5hLAxMGnuD6gGU-JNDOVc3jGhz41XWN788WA@mail.gmail.com>

Hi All,
    I tried to download the latest mac version of XSD and tried to compile
the hello project following the README file to build an example.

> $ cd examples/cxx/tree/hello

$ make

The error is:

Xiaos-MBP:hello Sean$ make

g++ -W -O3  -o driver driver.o hello.o -lxerces-c

Undefined symbols for architecture x86_64:

  "_CFRelease", referenced from:

      xercesc_3_1::MacOSUnicodeConverter::upperCase(unsigned short*) in
libxerces-c.a(MacOSUnicodeConverter.o)

      xercesc_3_1::MacOSUnicodeConverter::lowerCase(unsigned short*) in
libxerces-c.a(MacOSUnicodeConverter.o)

  "_CFStringCreateMutableWithExternalCharactersNoCopy", referenced from:

      xercesc_3_1::MacOSUnicodeConverter::upperCase(unsigned short*) in
libxerces-c.a(MacOSUnicodeConverter.o)

      xercesc_3_1::MacOSUnicodeConverter::lowerCase(unsigned short*) in
libxerces-c.a(MacOSUnicodeConverter.o)

  "_CFStringLowercase", referenced from:

      xercesc_3_1::MacOSUnicodeConverter::lowerCase(unsigned short*) in
libxerces-c.a(MacOSUnicodeConverter.o)

  "_CFStringUppercase", referenced from:

      xercesc_3_1::MacOSUnicodeConverter::upperCase(unsigned short*) in
libxerces-c.a(MacOSUnicodeConverter.o)

  "_CreateTextEncoding", referenced from:

      xercesc_3_1::MacOSUnicodeConverter::discoverLCPEncoding() in
libxerces-c.a(MacOSUnicodeConverter.o)


xercesc_3_1::MacOSUnicodeConverter::makeNewLCPTranscoder(xercesc_3_1::MemoryManager*)
in libxerces-c.a(MacOSUnicodeConverter.o)

      xercesc_3_1::MacOSUnicodeConverter::makeNewXMLTranscoder(unsigned
short const*, xercesc_3_1::XMLTransService::Codes&, unsigned long, unsigned
int, xercesc_3_1::MemoryManager*) in libxerces-c.a(MacOSUnicodeConverter.o)

  "_TECClearConverterContextInfo", referenced from:

      xercesc_3_1::MacOSTranscoder::transcodeFrom(unsigned char const*,
unsigned long, unsigned short*, unsigned long, unsigned long&, unsigned
char*) in libxerces-c.a(MacOSUnicodeConverter.o)

      xercesc_3_1::MacOSTranscoder::transcodeTo(unsigned short const*,
unsigned long, unsigned char*, unsigned long, unsigned long&,
xercesc_3_1::XMLTranscoder::UnRepOpts) in
libxerces-c.a(MacOSUnicodeConverter.o)

      xercesc_3_1::MacOSTranscoder::canTranscodeTo(unsigned int) in
libxerces-c.a(MacOSUnicodeConverter.o)

  "_TECConvertText", referenced from:

      xercesc_3_1::MacOSTranscoder::transcodeFrom(unsigned char const*,
unsigned long, unsigned short*, unsigned long, unsigned long&, unsigned
char*) in libxerces-c.a(MacOSUnicodeConverter.o)

      xercesc_3_1::MacOSTranscoder::transcodeTo(unsigned short const*,
unsigned long, unsigned char*, unsigned long, unsigned long&,
xercesc_3_1::XMLTranscoder::UnRepOpts) in
libxerces-c.a(MacOSUnicodeConverter.o)

      xercesc_3_1::MacOSTranscoder::canTranscodeTo(unsigned int) in
libxerces-c.a(MacOSUnicodeConverter.o)

  "_TECCreateConverter", referenced from:

      xercesc_3_1::MacOSUnicodeConverter::makeNewXMLTranscoder(unsigned
short const*, xercesc_3_1::XMLTransService::Codes&, unsigned long, unsigned
int, xercesc_3_1::MemoryManager*) in libxerces-c.a(MacOSUnicodeConverter.o)

  "_TECDisposeConverter", referenced from:

      xercesc_3_1::MacOSUnicodeConverter::makeNewXMLTranscoder(unsigned
short const*, xercesc_3_1::XMLTransService::Codes&, unsigned long, unsigned
int, xercesc_3_1::MemoryManager*) in libxerces-c.a(MacOSUnicodeConverter.o)

      xercesc_3_1::MacOSTranscoder::~MacOSTranscoder() in
libxerces-c.a(MacOSUnicodeConverter.o)

      xercesc_3_1::MacOSTranscoder::~MacOSTranscoder() in
libxerces-c.a(MacOSUnicodeConverter.o)

      xercesc_3_1::MacOSTranscoder::~MacOSTranscoder() in
libxerces-c.a(MacOSUnicodeConverter.o)

  "_TECGetTextEncodingFromInternetName", referenced from:

      xercesc_3_1::MacOSUnicodeConverter::makeNewXMLTranscoder(unsigned
short const*, xercesc_3_1::XMLTransService::Codes&, unsigned long,
xercesc_3_1::MemoryManager*) in libxerces-c.a(MacOSUnicodeConverter.o)

  "_UCCompareText", referenced from:

      xercesc_3_1::MacOSUnicodeConverter::compareIString(unsigned short
const*, unsigned short const*) in libxerces-c.a(MacOSUnicodeConverter.o)

      xercesc_3_1::MacOSUnicodeConverter::compareNIString(unsigned short
const*, unsigned short const*, unsigned long) in
libxerces-c.a(MacOSUnicodeConverter.o)

  "_UCCreateCollator", referenced from:


xercesc_3_1::MacOSUnicodeConverter::MacOSUnicodeConverter(xercesc_3_1::MemoryManager*)
in libxerces-c.a(MacOSUnicodeConverter.o)


xercesc_3_1::MacOSUnicodeConverter::MacOSUnicodeConverter(xercesc_3_1::MemoryManager*)
in libxerces-c.a(MacOSUnicodeConverter.o)

  "_UCDisposeCollator", referenced from:

      xercesc_3_1::MacOSUnicodeConverter::~MacOSUnicodeConverter() in
libxerces-c.a(MacOSUnicodeConverter.o)

      xercesc_3_1::MacOSUnicodeConverter::~MacOSUnicodeConverter() in
libxerces-c.a(MacOSUnicodeConverter.o)

      xercesc_3_1::MacOSUnicodeConverter::~MacOSUnicodeConverter() in
libxerces-c.a(MacOSUnicodeConverter.o)

  "_UpgradeScriptInfoToTextEncoding", referenced from:

      xercesc_3_1::MacOSUnicodeConverter::discoverLCPEncoding() in
libxerces-c.a(MacOSUnicodeConverter.o)


xercesc_3_1::MacOSUnicodeConverter::makeNewLCPTranscoder(xercesc_3_1::MemoryManager*)
in libxerces-c.a(MacOSUnicodeConverter.o)

  "_kCFAllocatorDefault", referenced from:

      xercesc_3_1::MacOSUnicodeConverter::upperCase(unsigned short*) in
libxerces-c.a(MacOSUnicodeConverter.o)

      xercesc_3_1::MacOSUnicodeConverter::lowerCase(unsigned short*) in
libxerces-c.a(MacOSUnicodeConverter.o)

  "_kCFAllocatorNull", referenced from:

      xercesc_3_1::MacOSUnicodeConverter::upperCase(unsigned short*) in
libxerces-c.a(MacOSUnicodeConverter.o)

      xercesc_3_1::MacOSUnicodeConverter::lowerCase(unsigned short*) in
libxerces-c.a(MacOSUnicodeConverter.o)

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see
invocation)

make: *** [driver] Error 1


My mac version is:

OXS Yosemite Version 10.10.2

My clang version is :

Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)

Target: x86_64-apple-darwin14.1.0

Thread model: posix