From s.mangelsdorf at gmail.com  Fri Nov  2 02:30:15 2007
From: s.mangelsdorf at gmail.com (Shaun Mangelsdorf)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] SOAP/1.2 schema issue with xsd cxx-tree
Message-ID: <90ad28f40711012330iad8fc9ap54dd48970dff4a8b@mail.gmail.com>

Hi xsd-users,

I am having a problem compiling the SOAP/1.2 schema from:
http://www.w3.org/2003/05/soap-envelope/

Output is:
soap-1.2-envelope.xsd: error: 'http://www.w3.org/2001/xml.xsd' is not
a valid filesystem path

Modifying the <xs:import> element to point to the local file 'xml.xsd'
fixes this problem completely, but I am curious as to whether there is
a neater option than modifying a standard xml schema.

Is there something in the various --.*-regex options that I have missed?


Thanks,
Shaun Mangelsdorf


From boris at codesynthesis.com  Fri Nov  2 02:58:15 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] SOAP/1.2 schema issue with xsd cxx-tree
In-Reply-To: <90ad28f40711012330iad8fc9ap54dd48970dff4a8b@mail.gmail.com>
References: <90ad28f40711012330iad8fc9ap54dd48970dff4a8b@mail.gmail.com>
Message-ID: <20071102065815.GB30239@karelia>

Hi Shaun,

Shaun Mangelsdorf <s.mangelsdorf@gmail.com> writes:

> Modifying the <xs:import> element to point to the local file 'xml.xsd'
> fixes this problem completely, but I am curious as to whether there is
> a neater option than modifying a standard xml schema.
>
> Is there something in the various --.*-regex options that I have missed?

The only way at the moment is to modify the schema. But there has been
several requests for an option (or a map file) like this in the past so
we will add something for the next release.

Thanks for the suggestion!

Boris


From jnw at xs4all.nl  Tue Nov  6 13:53:19 2007
From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco])
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Attempting to access attribute xml:base.
Message-ID: <24957.194.109.230.85.1194375199.squirrel@webmail.xs4all.nl>

Hi Boris,

Thanks for your explanation. I have abandoned the attempts to get xsd to
generate the required code and resumed work on another implementation,
i.e. using DOM association in a customization of anyType. It now works on
version 3.1.0.a1 of xsd.

I've updated
http://www.xs4all.nl/~jnw/codesynthesis/xmlnamespace/index.html to reflect
the current status.

More below:

"Boris Kolpackov" <boris@codesynthesis.com> writes:
> Hi Jeroen,
>
> Jeroen N. Witmond [Bahco] <jnw@xs4all.nl> writes:
>
>> Instead I have gotten xsd to generate all required code in
>> a custom type, without making any changes to xsd itself.
>
> This is a clever trick. I see you use sed to re-map the XML Schema
> namespace to xml_schema_2 when compiling XmlNamespace.xsd in order to
> avoid name clashes. You can achieve the same result by adding the
> following options to the command line:
>
> --namespace-map http://www.w3.org/2001/XMLSchema=xml_schema_2

Funny thing is, this works only in one case, but not in another. :)
In
http://www.xs4all.nl/~jnw/codesynthesis/xmlnamespace/custom-anyType/Makefile
I have put comments on the make targets to show where it does or does not
work.

>
> Unfortunately, this whole approach has a number of deficiencies
> and won't work for the general case, as you have described in your
> other email.
>
> The problem is that anyType is quite a special type. It is a
> root of the generated type hierarchy and as such is a base
> for both simple types (i.e., type with only text content)
> and complex types (i.e., types with attributes and/or elements).
>
> Because simple types can be used as attribute and list element
> types, anyType includes parsing constructors for DOMAttr, etc.
>
> On the other hand, complex types cannot be used as attribute
> or list element types. Because of this restriction, XSD does
> not generate those constructors (DOMAttr, etc.) for complex
> types.
>
> Now if we look at your XmlNamespace.xsd:
>
>   <complexType name="wrapper_type">
>     <complexContent>
>       <extension base="anyType">
>         <attribute ref="xml:base"/>
>       </extension>
>     </complexContent>
>   </complexType>
>
> This type is a complex type because it contains the xml:base attribute.
> As a result the attribute/list constructors are not generated. But when
> you try to use it as anyType, those constructors are required.
>
> Boris
>

Jeroen.


From rnell at sempratrading.com  Tue Nov  6 10:15:03 2007
From: rnell at sempratrading.com (Nell, Roger)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Bug: Paths not supported?
Message-ID: <577CF6D3F0AF83489727B5D50F31E2D80987CC12@STMAIL1.SEMPRATRADING.COM>

Below I have run the xsd.exe on a Windows XP, Professional x64 edition,
Service pack 2.

#1 shows a path to the CheckStatus.xsd file and the program exits with
an error.
#2 shows the same command line but with no path and the program
functions normally.


#1
C:\projects\StorageModel\CheckStatus>xsd cxx-tree --namespace-map
"http://sempr
/docs/sif/2.0/CheckStatus.xsd=CheckStatusXsd" --generate-doxygen
--generate-ost
eam  --hxx-suffix .h --cxx-suffix .cpp --generate-serialization
c:\projects\Sto
ageModel\CheckStatus\CheckStatus.xsd

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.

#2
C:\projects\StorageModel\CheckStatus>xsd cxx-tree --namespace-map
"http://sempr
/docs/sif/2.0/CheckStatus.xsd=CheckStatusXsd" --generate-doxygen
--generate-ost
eam  --hxx-suffix .h --cxx-suffix .cpp --generate-serialization
CheckStatus.xsd

C:\projects\StorageModel\CheckStatus>dir
c:\projects\StorageModel\CheckStatus\C
eckStatus.xsd
 Volume in drive C has no label.
 Volume Serial Number is C8B6-6012

 Directory of c:\projects\StorageModel\CheckStatus

11/01/2007  05:07 PM               916 CheckStatus.xsd
               1 File(s)            916 bytes
               0 Dir(s)  61,479,874,560 bytes free

C:\projects\StorageModel\CheckStatus>






****************************************************************************
This e-mail contains privileged attorney-client communications and/or confidential information,
and is only for the use by the intended recipient. Receipt by an unintended recipient does not
constitute a waiver of any applicable privilege.

Reading, disclosure, discussion, dissemination, distribution or copying of this information by
anyone other than the intended recipient or his or her employees or agents is strictly prohibited. If
you have received this communication in error, please immediately notify us and delete the
original material from your computer.

Sempra Energy Trading LLC (SET) is not the same company as SDG&E or SoCalGas, the
utilities owned by SET's parent company.  SET is not regulated by the California Public Utilities
Commission and you do not have to buy SET's products and services to continue to receive
quality regulated service from the utilities.

Sempra Energy Europe disclosure: Sempra Energy Europe Limited registered in England & Wales No.
3704235 registered office 111 Old Broad Street London EC2N 1SE United Kingdom.  Sempra
Energy Trading (UK) Limited registered in England & Wales No. 3526627 registered office 111
Old Broad Street London EC2N 1SE United Kingdom FSA firm reference number 188751.  Sempra
Energy Trading Holdings Limited registered in England & Wales No. 3704239 registered office 111
Old Broad Street London EC2N 1SE United Kingdom.
***************************************************************************


From boris at codesynthesis.com  Tue Nov  6 15:39:04 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Bug: Paths not supported?
In-Reply-To: <577CF6D3F0AF83489727B5D50F31E2D80987CC12@STMAIL1.SEMPRATRADING.COM>
References: <577CF6D3F0AF83489727B5D50F31E2D80987CC12@STMAIL1.SEMPRATRADING.COM>
Message-ID: <20071106203904.GC13436@karelia>

Hi Roger,

Nell, Roger <rnell@sempratrading.com> writes:

> Below I have run the xsd.exe on a Windows XP, Professional x64 edition,
> Service pack 2.

I tried to reproduce this problem on 32 bit WinXP (also Pro/SP2) without
any luck. I will try it on a 64 bit box tomorrow. From the command line,
I gather you are using XSD 3.0.0. Also did you use the standard Windows
command prompt to execute these command?

Thanks,
Boris


From boris at codesynthesis.com  Wed Nov  7 12:10:44 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Bug: Paths not supported?
In-Reply-To: <577CF6D3F0AF83489727B5D50F31E2D80987CC60@STMAIL1.SEMPRATRADING.COM>
References: <577CF6D3F0AF83489727B5D50F31E2D80987CC12@STMAIL1.SEMPRATRADING.COM>
	<20071106203904.GC13436@karelia>
	<577CF6D3F0AF83489727B5D50F31E2D80987CC60@STMAIL1.SEMPRATRADING.COM>
Message-ID: <20071107171044.GB2969@karelia>

Hi Roger,

I've CC'ed the xsd-users mailing list to my reply so that other
can keep track of this problem.

Nell, Roger <rnell@sempratrading.com> writes:

> Yes, standard cmd.exe.
>
> C:\>xsd version
>
> CodeSynthesis XSD XML Schema to C++ compiler 3.0.0
>
> I use a batch file to run xsd: xsd-compile.bat, containing:
>
> xsd cxx-tree --namespace-map
> "http://sempra/docs/sif/2.0/CheckStatus.xsd=CheckStatusXsd"
> --generate-doxygen --generate-ostream --generate-serialization
> --hxx-suffix .h --cxx-suffix .cpp %1
>
> I get the 'terminated in an unusual way' error if I call it like this:
>
> cd \projects\StorageModel\StorageModelService
>
> xsd-compile c:\projects\StorageModel\StorageModelService\CheckStatus.xsd
>
> And this works:
>
> xsd-compile CheckStatus.xsd

I tried this on 64 bit Windows Server 2003 and it works fine. So I
will need your help in narrowing this down. Is there anything special
in CheckStatus.xsd? For example, does it contain any import or include
declarations? When you compile it using the file name only, are there
any errors?

Also what happens if you don't use the .bat file and instead type the
command line with the absolute schema path directly into the command
prompt? Is there any difference if you remove all the options from the
command line?

Can someone else with a 64 bit WinXP Pro/SP2 box give it a try and see
if you can reproduce this problem?

Thanks,
Boris


From boris at codesynthesis.com  Thu Nov  8 13:55:13 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Bug: Paths not supported?
In-Reply-To: <577CF6D3F0AF83489727B5D50F31E2D80987CCBF@STMAIL1.SEMPRATRADING.COM>
References: <577CF6D3F0AF83489727B5D50F31E2D80987CC12@STMAIL1.SEMPRATRADING.COM>
	<20071106203904.GC13436@karelia>
	<577CF6D3F0AF83489727B5D50F31E2D80987CC60@STMAIL1.SEMPRATRADING.COM>
	<20071107171044.GB2969@karelia>
	<577CF6D3F0AF83489727B5D50F31E2D80987CCBF@STMAIL1.SEMPRATRADING.COM>
Message-ID: <20071108185513.GG4673@karelia>

Hi Roger,

Nell, Roger <rnell@sempratrading.com> writes:

> The problem seems to be around a combination of absolute path input file
> and the doxygen option.  I've attached my doxyfile.

Thanks to your detective work I could reproduce the bug on my 32 bit
WinXP and fix it.

If you are interested in details, the generated doxygen documentation
for the file includes the schema name from which the C++ file was
generated (@file comment). The code in XSD was writing that schema
path in the "portable" format instead of "native". While simple
file names such as schema.xsd are representable in portable format,
absolute Windows paths (e.g., C:\dir\schema.xsd) are not. The fixed
code now uses native format.

If you would like, I can built you a new binary with this fix.

Thanks,
Boris


From jnw at xs4all.nl  Thu Nov  8 16:37:36 2007
From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco])
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] For <xs:restriction base="xs:anyType"> generated code
 does not compile.
Message-ID: <14113.194.109.230.85.1194557856.squirrel@webmail.xs4all.nl>

Greetings,

When I try to generate code for a Schema containing
<xs:restriction base="xs:anyType">
(my guess for the problem) it does not compile. The Schema file and
Makefile attached demonstrate the problem. They do not use any kind of
type customization.

The error is "error: no match for 'operator<<' in 'o << (const
xml_schema::type&)(&((const
metadox::problem*)i)->metadox::problem::<anonymous>)'". As expected, the
problem disappears when --generate-ostream is removed from the xsd
command.

The problem exists in versions 3.0.0 and 3.1.0.a1 of xsd. Code generated
by version 2.3.0 compiles without errors, but I have not tried to use it.

Regards,

Jeroen.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: restrict-base-anytype.xsd
Type: application/octet-stream
Size: 483 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071108/4c6266ff/restrict-base-anytype.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 2586 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071108/4c6266ff/Makefile.obj
From Clyde.Bourne at genband.com  Thu Nov  8 14:59:12 2007
From: Clyde.Bourne at genband.com (Chip Bourne)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Lines truncated in ostream at 132 characters.
Message-ID: <F4D184340C82424BBBD6F020CCCBD6CC066C36F1@gbausmail.genband.com>


It appears that my output of elements to an ostream is truncated at 132
characters/line.
It happens with elements that contain many attributes.

          <gtindicator0100 encoding-scheme="ES_ODD"
nature-of-addr-ind="NA_SUBSCRIBER" numbering-plan="NP_ISDN_TEL"
translation-typ>

Should read:
          <gtindicator0100 encoding-scheme="ES_ODD"
nature-of-addr-ind="NA_SUBSCRIBER" numbering-plan="NP_ISDN_TEL"
translation-type="1">

I am using version: XML Schema Definition Compiler 2.3.1

Any help would be greatly appreciated.
 
 

Chip Bourne
Applications Business Unit

GENBAND Inc.
3701 W. Plano Pkwy., Suite 200
Plano, TX 75075 USA
office            +1.972.372.5026
mobile         +1.214.558.8897
facsimile     +1.972.238.1749
chip.bourne@genband.com
 
 <http://www.genband.com/> 
 



From boris at codesynthesis.com  Thu Nov  8 16:51:29 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Lines truncated in ostream at 132 characters.
In-Reply-To: <F4D184340C82424BBBD6F020CCCBD6CC066C36F1@gbausmail.genband.com>
References: <F4D184340C82424BBBD6F020CCCBD6CC066C36F1@gbausmail.genband.com>
Message-ID: <20071108215129.GH4673@karelia>

Hi Chip,

Chip Bourne <Clyde.Bourne@genband.com> writes:

> It appears that my output of elements to an ostream is truncated at 132
> characters/line. It happens with elements that contain many attributes.

I just tried to serialize an XML instance with root element tag being
more that 200 characters long and I don't get any truncations. Can
you provide a small example that reproduces the problem? What version
on Xerces-C++ are you using?

Thanks,
Boris


From bruno.marotta at fortis.com  Fri Nov  9 05:12:25 2007
From: bruno.marotta at fortis.com (bruno.marotta@fortis.com)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Basic questions
Message-ID: <8E2E628CE354934FAB31A90699BCFA0D0248F334@spmw0018.mail.shared.fortis>


Hi,

I just started with XSD C++ Data Binding. I have to generate a xml from scratch. I have already succesfully generated the headers for xsd files.

The thing is that main xsd doesn't define its type:


<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XML Spy v4.3 U (http://www.xmlspy.com) by mike (McGraw-Hill) -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:include schemaLocation="CDOInputForHeader.xsd"/>
	<xs:include schemaLocation="CDOInputForSDR.xsd"/>
	<xs:include schemaLocation="CDOInputForReport.xsd"/>
	<xs:element name="CDOEvaluator"/>
</xs:schema>


The xml I have to generate is something like this:

<CDOEvaluator>
	<InputForSDR>
...

I can create my CDOEvaluator and InputForSDR node like this:

	xml_schema::type cdoEvaluator
	...
	InputForSDR inputForSDR(p);

But how can I add the inputForSDR to the cdoEvaluator?

Thanks,

Bruno
-------------- next part --------------

= = = = = = = = = = = = = = = = = = = = = = = = =
Fortis disclaimer :
http://www.fortis.be/legal/disclaimer.htm

Privacy policy related to banking activities of Fortis:
http://www.fortis.be/legal/privacy_policy.htm
= = = = = = = = = = = = = = = = = = = = = = = = =

From boris at codesynthesis.com  Fri Nov  9 07:43:43 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Basic questions
In-Reply-To: <8E2E628CE354934FAB31A90699BCFA0D0248F334@spmw0018.mail.shared.fortis>
References: <8E2E628CE354934FAB31A90699BCFA0D0248F334@spmw0018.mail.shared.fortis>
Message-ID: <20071109124343.GD8043@karelia>

Hi Bruno,

bruno.marotta@fortis.com <bruno.marotta@fortis.com> writes:

> The thing is that main xsd doesn't define its type:
>
> 	<xs:element name="CDOEvaluator"/>

This declaration is equivalent to:

<xs:element name="CDOEvaluator" type="xs:anyType"/>

Which means CDOEvaluator element can contain pretty much anything
and no validation will be done on its content. This most likely is
not something that the author of the schema intended, but if it
is then read on.


> The xml I have to generate is something like this:
>
> <CDOEvaluator>
> 	<InputForSDR>
> ...
>
> I can create my CDOEvaluator and InputForSDR node like this:
>
> 	xml_schema::type cdoEvaluator
> 	...
> 	InputForSDR inputForSDR(p);
>
> But how can I add the inputForSDR to the cdoEvaluator?


You cannot since xml_schema::type (mapping for xsd:anyType) does not
know anything about InputForSDR or any other content.

If there is global element InputForSDR defined in one of your schemas,
then you can write the <CDOEvaluator> openning tag and </CDOEvaluator>
closing tag yourself and then serialize InputForSDR using the XSD-generated
object model (you will need to pass the no_xml_declaration flag to the
serializer function). For an example that does pretty much exactly this
see examples/cxx/tree/streaming/ in the XSD distribution.

If you do not have the InputForSDR element (and cannot change the
schema to define one) then things are bit more complicated. You will
need to (1) create a DOMDocument with the CDOEvaluator as root element,
(2) add the InputForSDR element under it, then (3) serialize the
InputForSDR instance (inputForSDR) into InputForSDR element, and,
finally, (4) serialize the DOM document to XML.

Steps 1, 2, and 4 are covered in the C++/Tree Mapping FAQ, Section 3:

http://wiki.codesynthesis.com/Tree/FAQ

Step 3 is actually quite easy:

DOMElement* inputForSDRElement = ...;

*inputForSDRElement << inputForSDR;


Let me know if you run into any problems.

Boris


From bruno.marotta at fortis.com  Fri Nov  9 07:57:03 2007
From: bruno.marotta at fortis.com (bruno.marotta@fortis.com)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Basic questions
In-Reply-To: <20071109124343.GD8043@karelia>
Message-ID: <8E2E628CE354934FAB31A90699BCFA0D0248F336@spmw0018.mail.shared.fortis>

Hi Boris,

thanks for the reply. For what I've understood, I will have to a mix between the XSD utility functions and the pure Xerces one. 

I will try it and I'll let you know.

Thanks,

Bruno 

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Friday, November 09, 2007 1:44 PM
To: Marotta Bruno
Cc: xsd-users@codesynthesis.com
Subject: Re: [xsd-users] Basic questions

Hi Bruno,

bruno.marotta@fortis.com <bruno.marotta@fortis.com> writes:

> The thing is that main xsd doesn't define its type:
>
> 	<xs:element name="CDOEvaluator"/>

This declaration is equivalent to:

<xs:element name="CDOEvaluator" type="xs:anyType"/>

Which means CDOEvaluator element can contain pretty much anything
and no validation will be done on its content. This most likely is
not something that the author of the schema intended, but if it
is then read on.


> The xml I have to generate is something like this:
>
> <CDOEvaluator>
> 	<InputForSDR>
> ...
>
> I can create my CDOEvaluator and InputForSDR node like this:
>
> 	xml_schema::type cdoEvaluator
> 	...
> 	InputForSDR inputForSDR(p);
>
> But how can I add the inputForSDR to the cdoEvaluator?


You cannot since xml_schema::type (mapping for xsd:anyType) does not
know anything about InputForSDR or any other content.

If there is global element InputForSDR defined in one of your schemas,
then you can write the <CDOEvaluator> openning tag and </CDOEvaluator>
closing tag yourself and then serialize InputForSDR using the XSD-generated
object model (you will need to pass the no_xml_declaration flag to the
serializer function). For an example that does pretty much exactly this
see examples/cxx/tree/streaming/ in the XSD distribution.

If you do not have the InputForSDR element (and cannot change the
schema to define one) then things are bit more complicated. You will
need to (1) create a DOMDocument with the CDOEvaluator as root element,
(2) add the InputForSDR element under it, then (3) serialize the
InputForSDR instance (inputForSDR) into InputForSDR element, and,
finally, (4) serialize the DOM document to XML.

Steps 1, 2, and 4 are covered in the C++/Tree Mapping FAQ, Section 3:

http://wiki.codesynthesis.com/Tree/FAQ

Step 3 is actually quite easy:

DOMElement* inputForSDRElement = ...;

*inputForSDRElement << inputForSDR;


Let me know if you run into any problems.

Boris


= = = = = = = = = = = = = = = = = = = = = = = = =
Fortis disclaimer :
http://www.fortis.be/legal/disclaimer.htm

Privacy policy related to banking activities of Fortis:
http://www.fortis.be/legal/privacy_policy.htm
= = = = = = = = = = = = = = = = = = = = = = = = =




From boris at codesynthesis.com  Fri Nov  9 07:58:58 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Basic questions
In-Reply-To: <8E2E628CE354934FAB31A90699BCFA0D0248F336@spmw0018.mail.shared.fortis>
References: <20071109124343.GD8043@karelia>
	<8E2E628CE354934FAB31A90699BCFA0D0248F336@spmw0018.mail.shared.fortis>
Message-ID: <20071109125858.GF8043@karelia>

Hi Bruno,

bruno.marotta@fortis.com <bruno.marotta@fortis.com> writes:

> For what I've understood, I will have to a mix between the XSD
> utility functions and the pure Xerces one.

Well, yes, this is a somewhat common theme in using the C++/Tree
mapping: when there is something you cannot do in a statically-
typed object model, you can always get under the hood and do it
directly in the DOM document. Much of the C++/Tree flexibility
comes from this and the customization mechanisms.

Boris


From bruno.marotta at fortis.com  Fri Nov  9 10:14:05 2007
From: bruno.marotta at fortis.com (bruno.marotta@fortis.com)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Basic questions
In-Reply-To: <20071109125858.GF8043@karelia>
Message-ID: <8E2E628CE354934FAB31A90699BCFA0D0248F339@spmw0018.mail.shared.fortis>

Another question: Is it possible to have all type definitions (xml_schema::type) defined in only one hxx ?

Thanks 

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Friday, November 09, 2007 1:59 PM
To: Marotta Bruno
Cc: xsd-users@codesynthesis.com
Subject: Re: [xsd-users] Basic questions

Hi Bruno,

bruno.marotta@fortis.com <bruno.marotta@fortis.com> writes:

> For what I've understood, I will have to a mix between the XSD
> utility functions and the pure Xerces one.

Well, yes, this is a somewhat common theme in using the C++/Tree
mapping: when there is something you cannot do in a statically-
typed object model, you can always get under the hood and do it
directly in the DOM document. Much of the C++/Tree flexibility
comes from this and the customization mechanisms.

Boris


= = = = = = = = = = = = = = = = = = = = = = = = =
Fortis disclaimer :
http://www.fortis.be/legal/disclaimer.htm

Privacy policy related to banking activities of Fortis:
http://www.fortis.be/legal/privacy_policy.htm
= = = = = = = = = = = = = = = = = = = = = = = = =




From Clyde.Bourne at genband.com  Fri Nov  9 10:24:25 2007
From: Clyde.Bourne at genband.com (Chip Bourne)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Lines truncated in ostream at 132 characters.
In-Reply-To: <20071108215129.GH4673@karelia>
Message-ID: <F4D184340C82424BBBD6F020CCCBD6CC0672DF33@gbausmail.genband.com>

Boris,

Total brain cramp on my part; it was my terminal that was truncating my
output. 

Sorry all,
Chip

--------------------------
Chip Bourne
Applications Business Unit
GENBAND, Inc.
office         +1.972.372.5026
mobile         +1.214.558.8897
chip.bourne@genband.com



-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Thursday, November 08, 2007 3:51 PM
To: Chip Bourne
Cc: xsd-users@codesynthesis.com
Subject: Re: [xsd-users] Lines truncated in ostream at 132 characters.

Hi Chip,

Chip Bourne <Clyde.Bourne@genband.com> writes:

> It appears that my output of elements to an ostream is truncated at 
> 132 characters/line. It happens with elements that contain many
attributes.

I just tried to serialize an XML instance with root element tag being
more that 200 characters long and I don't get any truncations. Can you
provide a small example that reproduces the problem? What version on
Xerces-C++ are you using?

Thanks,
Boris


From Clyde.Bourne at genband.com  Fri Nov  9 10:59:34 2007
From: Clyde.Bourne at genband.com (Chip Bourne)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] hexBinary question.
Message-ID: <F4D184340C82424BBBD6F020CCCBD6CC0672DF7E@gbausmail.genband.com>

 
I have BCD byte values that I want to represent in a xsd:hexBinary
schema element, but I seem to be running into some sort of signing
problem.  When I construct an xml_schema::hex_binary with values greater
than 0x7f I abort.  What am I doing wrong?  Shouldn't hex_binary handle
this?

So,
            <?xml version="1.0" encoding="UTF-8"?>
            <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
                  <xs:element name="gtindicatorBCD"
type="xs:hexBinary"/>
            </xs:schema>

But when I try to marshal the following I abort after 0x7f

            #include "test.hxx"
            #include <string>
            #include <list>
            #include<iostream>
            #include<fstream>
            using namespace std;

            int main(int argc, void *argv[])
            {
                  for (unsigned char ii = 0; ii < 255; ii++)
                  {
                        xml_schema::namespace_infomap map;
                            map[""].name = "";
                            map[""].schema = "";

                        gtindicatorBCD(cout, xml_schema::hex_binary(&ii,
sizeof(ii)), map);
                  }
                  return 0;
            } 

I'm using xsd compiler version 
	XML Schema Definition Compiler 2.3.1

I can see that the encoding of a hexBinary does not handle values
greater than 127 properly; I just don't know if it should.
---from xsd/cxx/tree/types.txx	
      template <typename C, typename B>
      std::basic_string<C> hex_binary<C, B>::
      encode () const
      {
        std::basic_string<C> str;

        const char tab[] = "0123456789ABCDEF";

        if (size_t n = this->size ())
        {
          str.reserve (2 * n + 1);
          str.resize (2 * n);

          for (size_t i (0); i < n; ++i)
          {
            char byte (*(this->data () + i));
		/****** this shift drags sign ***********/
            unsigned char h (byte >> 4);
            unsigned char l (byte & 0x0F);

            str[2 * i] = C (tab[h]);
            str[2 * i + 1] = C (tab[l]);
          }
        }

Chip Bourne
Applications Business Unit

GENBAND Inc.
3701 W. Plano Pkwy., Suite 200
Plano, TX 75075 USA
office            +1.972.372.5026
mobile         +1.214.558.8897
facsimile     +1.972.238.1749
chip.bourne@genband.com
 
 <http://www.genband.com/> 
 



From boris at codesynthesis.com  Fri Nov  9 15:06:33 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] hexBinary question.
In-Reply-To: <F4D184340C82424BBBD6F020CCCBD6CC0672DF7E@gbausmail.genband.com>
References: <F4D184340C82424BBBD6F020CCCBD6CC0672DF7E@gbausmail.genband.com>
Message-ID: <20071109200633.GA9086@karelia>

Hi Chip,

Chip Bourne <Clyde.Bourne@genband.com> writes:

>
> I have BCD byte values that I want to represent in a xsd:hexBinary
> schema element, but I seem to be running into some sort of signing
> problem.  When I construct an xml_schema::hex_binary with values greater
> than 0x7f I abort.  What am I doing wrong?  Shouldn't hex_binary handle
> this?

I am pretty sure you are running into a well-known bug. It is fixed
in 3.0.0 and for 2.3.1 there is a patch:

http://codesynthesis.com/~boris/tmp/xsd-2.3.1-hex-binary.patch

Boris


From boris at codesynthesis.com  Fri Nov  9 15:15:17 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Basic questions
In-Reply-To: <8E2E628CE354934FAB31A90699BCFA0D0248F339@spmw0018.mail.shared.fortis>
References: <20071109125858.GF8043@karelia>
	<8E2E628CE354934FAB31A90699BCFA0D0248F339@spmw0018.mail.shared.fortis>
Message-ID: <20071109201517.GC9086@karelia>

Hi Bruno,

bruno.marotta@fortis.com <bruno.marotta@fortis.com> writes:

> Another question: Is it possible to have all type definitions
> (xml_schema::type) defined in only one hxx ?

Yes, see the --generate-xml-schema and --extern-xml-schema options
in the XSD Compiler Command Line Manual:

http://www.codesynthesis.com/projects/xsd/documentation/xsd.xhtml

An example that shows how to use these options can be found in
Section 4 of the C++/Tree Mapping Customization Guide:

http://wiki.codesynthesis.com/Tree/Customization_guide

Boris


From boris at codesynthesis.com  Mon Nov 12 01:47:27 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Re: Help needed xsd::short to str
In-Reply-To: <47356A18.2000305@intrepid-geophysics.com>
References: <47356A18.2000305@intrepid-geophysics.com>
Message-ID: <20071112064727.GB16982@karelia>

Hi Waqqas,

In the future please send technical questions like these to the
xsd-users mailing list (which I've CC'ed) instead of to me directly.
This way a) other developers who may have experienced a similar
problem can provide you with a solution b) questions and answers
will be archived and available to others with similar problems.

Waqqas Sharif <waqqas@intrepid-geophysics.com> writes:

> I have got a quick question for you, which in my schema i have got
> one attribute defined as xsd::short. Is it possible to get this value as
> a string.  As far as i know when you try to access this object you get
> back a short. I can do the conversion myself, but just wondering is
> there any other way of doing this with XSD.

Converting this value from short to string is probably the easiest
way. You can use std::ostringstream, for example.

If you need to get the value exactly as it appears in XML, then you
will need to extract it from DOM yourself. There are two way to do
this.

The first is to use the DOM association feature. This way you can
keep the DOM tree around with each object model node associated
with the corresponding DOM node. For more information on this
see the mixed example in the examples/cxx/tree/ directory.

The second approach is to customize the type that contains this
float attribute and extract the string representation during
parsing. The advantage of this approach over the previous one
is that you don't need to keep the whole DOM tree around. For
more information on how to customize the generated types see
the C++/Tree Mapping Customization Guide:

http://wiki.codesynthesis.com/Tree/Customization_guide

And the 'wildcard' example in the examples/cxx/tree/custom/
directory.

Boris


From Michael.Forstner at cpg.de  Tue Nov 13 05:29:09 2007
From: Michael.Forstner at cpg.de (Forstner Michael)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Error "Not valid after content" on Solaris 9
Message-ID: <A1D90A1E7DDE7043A8494347CCE28A3E070193@mail1.cpg.de>

Hi all,

I am experiencing a problem which is maybe xerces-c related but I am not sure:
I am trying to parse an XML stream to a Xerces-C++ DOM-Element as described in
the wiki: http://wiki.codesynthesis.com/Tree/FAQ#How_do_I_parse_an_XML_document_to_a_Xerces-C.2B.2B_DOM_document.3F

On Windows it works like a charm but on Solaris I get an "Not valid after content" exception
in the XMLScanner::scanMiscellaneous() routine of Xerces-C.

I've tried Xerces-C 2.7 and 2.8 precompiled and also 2.8 self compiled - always with the same
result.

I am missing a compiler-flag or something else for Solaris9 (SPARC) with SunStudio 11?

Thanks,
Michael Forstner


From boris at codesynthesis.com  Tue Nov 13 05:47:48 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] XSD/e 2.0.0 released
Message-ID: <20071113104748.GC15207@karelia>

Hi,

We have released XSD/e 2.0.0. This release adds the new
Embedded C++/Serializer mapping which provides event-driven
XML serialization, XML Schema validation, and C++ data
binding. For more information on this mapping see:

http://www.codesynthesis.com/products/xsde/c++/serializer/


As well as the Embedded C++/Serializer Mapping Getting Started Guide:

http://www.codesynthesis.com/projects/xsde/documentation/cxx/serializer/guide/


The other NEWS file entries for this release are as follows:

 C++/Parser

  * The argument order in the generated parsers() functions has
    changed from elements then attributes to attributes then
    elements.

  * A number of types in the xml_schema namespaces have been
    renamed in order to make the C++/Parser and C++/Serializer
    mappings usable in the same translation unit. The old and
    new names are listed below:

    document         document_pimpl
    exception        parser_exception
    xml              parser_xml
    schema           parser_schema
    error            parser_error
    xml_error        parser_xml_error
    schema_error     parser_schema_error
    simple_content   parser_simple_content
    complex_content  parser_complex_content
    list_base        parser_list_base

  * The error accessor function has been renamed from error()
    to _error(). The application error modifier function has
    been renamed from error(int) to _app_error(int).

  * For each subsequent element with the same name in the same
    complex type, the mapping now produces a separate set of
    callbacks and accessors. Note that in this case the
    generated code will be able to perform correct dispatching
    only with XML Schema validation enabled. When validation is
    disabled all events will be delivered to the callback
    corresponding to the first element with this name.


Precompiled binary distributions are available from the product's
download page:

  http://www.codesynthesis.com/products/xsde/download.xhtml


Source code for this release is available from the project's web page:

  http://www.codesynthesis.com/projects/xsde/


SHA1 checksums for the files:

2ac7ba6801c7556eb3a6c5ae8c681a934737fb01  xsde-2.0.0.tar.bz2
556e1fdf482d6e67a5f22e9f5da2c00111cb1fab  xsde-2.0.0-i686-linux-gnu.tar.bz2
5dc38b15f630a0be4453e6a290993cc53bbf0089  xsde-2.0.0-sparc-solaris.tar.gz
29fe3dc22a9fb8b924b73e904c5a6c292bd30f6c  xsde-2.0.0-i686-windows.zip


Enjoy,
	Boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: Digital signature
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071113/87b162fe/attachment.pgp
From bayois at gmail.com  Tue Nov 13 06:07:02 2007
From: bayois at gmail.com (Alessio Fina)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] build-0.3 problem
Message-ID: <566e1eb00711130307y6e9a54e5of4d7872a4b05ab51@mail.gmail.com>

Hi All,
I just downloaded and tried to compile xsd-3.0.0 from source from
http://www.codesynthesis.com/download/xsd/3.0/xsd-3.0.0.tar.bz2
When I run 'make' I get the following error:

build/bootstrap.make:8: build-0.3/bootstrap.make: No such file or directory
make: *** No rule to make target `build-0.3/bootstrap.make'.  Stop.

I tried to download buil-0.3 source code and place under the xsd-3.0.0
source tree but didn't solve the probelme.

Could anyone please tell what's the problem may be?

Thanks!

aLe



"Unix never says please"
 ,= ,-__-. =.
((_/)o  o(\_))
   `-'(.   .)`-'
       \_/


From boris at codesynthesis.com  Tue Nov 13 06:29:00 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] build-0.3 problem
In-Reply-To: <566e1eb00711130307y6e9a54e5of4d7872a4b05ab51@mail.gmail.com>
References: <566e1eb00711130307y6e9a54e5of4d7872a4b05ab51@mail.gmail.com>
Message-ID: <20071113112900.GF15207@karelia>

Hi Alessio,

Alessio Fina <bayois@gmail.com> writes:

> I just downloaded and tried to compile xsd-3.0.0 from source from
> http://www.codesynthesis.com/download/xsd/3.0/xsd-3.0.0.tar.bz2
> When I run 'make' I get the following error:
>
> build/bootstrap.make:8: build-0.3/bootstrap.make: No such file or directory
> make: *** No rule to make target `build-0.3/bootstrap.make'.  Stop.
>
> I tried to download buil-0.3 source code and place under the xsd-3.0.0
> source tree but didn't solve the probelme.

Please see the build instructions for UNIX:

http://codesynthesis.com/projects/xsd/extras/build-unix.xhtml

Boris


From boris at codesynthesis.com  Tue Nov 13 06:36:14 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Error "Not valid after content" on Solaris 9
In-Reply-To: <A1D90A1E7DDE7043A8494347CCE28A3E070193@mail1.cpg.de>
References: <A1D90A1E7DDE7043A8494347CCE28A3E070193@mail1.cpg.de>
Message-ID: <20071113113614.GG15207@karelia>

Hi Michael,

Forstner Michael <Michael.Forstner@cpg.de> writes:

> On Windows it works like a charm but on Solaris I get an "Not valid
> after content" exception in the XMLScanner::scanMiscellaneous()
> routine of Xerces-C.
>
> I've tried Xerces-C 2.7 and 2.8 precompiled and also 2.8 self
> compiled - always with the same result.

Can you try to run one of the examples supplied with Xerces-C++
on your XML and see if you get the same error. You can use
DOMCount which comes pre-compiled in the 2.8.0 binary package.
If you have schema validation enabled, make sure you also
enable it when running DOMCount (DOMCount -h).

If you get the same error with Xerces-C++ examples then there
is either a problem in your XML or a bug in Xerces-C++. If
you can't figure out what it is, then feel free to send me
the XML/schema files and I will take a look.

If DOMCount works fine, then I will need a small test case
as well as the XML/schema files that reproduce the problem.

Thanks,
Boris


From boris at codesynthesis.com  Tue Nov 13 06:54:57 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Re: Access Violation when deleting objects
In-Reply-To: <8E2E628CE354934FAB31A90699BCFA0D0248F341@spmw0018.mail.shared.fortis>
References: <20071109201517.GC9086@karelia>
	<8E2E628CE354934FAB31A90699BCFA0D0248F341@spmw0018.mail.shared.fortis>
Message-ID: <20071113115457.GH15207@karelia>

Hi Bruno,

In the future please send technical questions like these to the
xsd-users mailing list (which I've CC'ed) instead of to me directly.
This way a) other developers who may have experienced a similar
problem can provide you with a solution b) questions and answers
will be archived and available to others with similar problems.

bruno.marotta@fortis.com <bruno.marotta@fortis.com> writes:


> I am still playing with your XSD classes. I think that I don't have
> to tell that I found them great.

Thanks, I am glad you like it.


> Not quite so easy to use, but when you get to known it flows smoothly.

Is it difficult to use before you've read the Getting Started Guide[1] or
after?

[1] http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/


> The thing is, now I am separting the interfaces on a dll, so I used
> the export option from the xsd generation. But, when some classes
> are freed, it throws an access violation. As these are hard to debug,
> I've starting decouping until I really isolated the problem. Basically
> I have one class like this:
>
> class __declspec(dllexport) ObligorID: public ::xml_schema::string

Do you really have __declspec(dllexport) there or is it some CPP macro
that changes from __declspec(dllexport) to __declspec(dllimport)?


> {
>   public:
>   // Constructors.
>   //
>   ObligorID ();
>
>   ObligorID (const ::xml_schema::string&);
>
>   ObligorID (const ::xercesc::DOMElement& e,
>              ::xml_schema::flags f = 0,
>              ::xml_schema::type* c = 0);
>
>   ObligorID (const ::xercesc::DOMAttr& a,
>              ::xml_schema::flags f = 0,
>              ::xml_schema::type* c = 0);
>
>   ObligorID (const ::std::string& s,
>              const ::xercesc::DOMElement* e,
>              ::xml_schema::flags f = 0,
>              ::xml_schema::type* c = 0);
>
>   ObligorID (const ObligorID& x,
>              ::xml_schema::flags f = 0,
>              ::xml_schema::type* c = 0);
>
>   virtual ObligorID*
>   _clone (::xml_schema::flags f = 0,
>           ::xml_schema::type* c = 0) const;
> };
>
> Which is fairly simple. On the executable where I call the dll, if I
> do a simple:
>
> 	ObligorID* obl = new ObligorID("131 xxxxxxxxxxxxxwxxxx");
> 	delete obl;
>
> As the first entries of the main, I get an exception on the delete.
> Do you have any idea where does this came from?

That's very strange. The usual suspect would be the cross-DLL memory
allocation/deallocation but here you create and delete the object in
main() so this can't be it. Just to confirm, can you change the
generated object code type in both your application and DLL to use
the DLL runtime and see if there is any change?

You may also want to step into the "delete obl" statement in the
debugger and see what's going on and where it crashes. Or you can
send me a small example that reproduces this problem and I will
take a look.


> Also, I am wondering why on the getters and setters of the classes
> sometimes you can simply pass a string (for the dates, for instance)
> and sometimes you mas pass an instantiated object from a string. Example:
>
> asset.MaturityDate("2005-01-01"); // Nice way of doing it
> asset.AssumedRecoveryLookup(AssumedRecoveryLookup("N")); // Why can't I just pass the "N"?

C++ does not allow chains of implicit conversions. In other words, if
you have class A that has an (implicit) constructor from const char*
and class B that has an (implicit) constructor from A and you have a
function f() with argument of type B, then you cannot pass "foo" to
it because that would require a chain of conversions:
const char*-> A -> B

In the above example, MaturityDate() has an argument which can be
implicitly constructed from a string literal while AssumedRecoveryLookup()
does not. Can you tell me what the AssumedRecoveryLookup schema type
looks like?

Boris


From bruno.marotta at fortis.com  Tue Nov 13 07:28:46 2007
From: bruno.marotta at fortis.com (bruno.marotta@fortis.com)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] RE: Access Violation when deleting objects
In-Reply-To: <20071113115457.GH15207@karelia>
Message-ID: <8E2E628CE354934FAB31A90699BCFA0D0248F34E@spmw0018.mail.shared.fortis>

Hi Boris,

thanks for the answers. About the memory I've found out. It is not linked to XSD at all. It is just a Microsoft thing where both the dll and executable should share the memory configuration.

About the string question as you may see here bellow the AssumedRecoveryLookup is a pure and simple string class. And it is only used on the asset class. So, why must it be a class and just a simple property from the Asset with type xml_schema::string? Isn't the transformation adding too much code for nothing? (if I go to cxx, the AssumedRecoveryLookup doesn't add any feature to the string class. What is its purpose then?)

(...)
class __declspec(dllexport) Asset (...)

  // AssumedRecoveryLookup
  // 
  typedef ::AssumedRecoveryLookup AssumedRecoveryLookup_type;
  typedef ::xsd::cxx::tree::optional< AssumedRecoveryLookup_type > AssumedRecoveryLookup_optional;
  typedef ::xsd::cxx::tree::traits< AssumedRecoveryLookup_type, char > AssumedRecoveryLookup_traits;

  const AssumedRecoveryLookup_optional&
  AssumedRecoveryLookup () const;

  AssumedRecoveryLookup_optional&
  AssumedRecoveryLookup ();

  void
  AssumedRecoveryLookup (const AssumedRecoveryLookup_type& x);

  void
  AssumedRecoveryLookup (const AssumedRecoveryLookup_optional& x);

  void
  AssumedRecoveryLookup (::std::auto_ptr< AssumedRecoveryLookup_type > p);
 (...)

class __declspec(dllexport) AssumedRecoveryLookup: public ::xml_schema::string
{
  public:
  // Constructors.
  //
  AssumedRecoveryLookup ();

  AssumedRecoveryLookup (const ::xml_schema::string&);

  AssumedRecoveryLookup (const ::xercesc::DOMElement& e,
                         ::xml_schema::flags f = 0,
                         ::xml_schema::type* c = 0);

  AssumedRecoveryLookup (const ::xercesc::DOMAttr& a,
                         ::xml_schema::flags f = 0,
                         ::xml_schema::type* c = 0);

  AssumedRecoveryLookup (const ::std::string& s,
                         const ::xercesc::DOMElement* e,
                         ::xml_schema::flags f = 0,
                         ::xml_schema::type* c = 0);

  AssumedRecoveryLookup (const AssumedRecoveryLookup& x,
                         ::xml_schema::flags f = 0,
                         ::xml_schema::type* c = 0);

  virtual AssumedRecoveryLookup*
  _clone (::xml_schema::flags f = 0,
          ::xml_schema::type* c = 0) const;
};

(...)

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Tuesday, November 13, 2007 12:55 PM
To: Marotta Bruno
Cc: xsd-users@codesynthesis.com
Subject: Re: Access Violation when deleting objects

Hi Bruno,

In the future please send technical questions like these to the
xsd-users mailing list (which I've CC'ed) instead of to me directly.
This way a) other developers who may have experienced a similar
problem can provide you with a solution b) questions and answers
will be archived and available to others with similar problems.

bruno.marotta@fortis.com <bruno.marotta@fortis.com> writes:


> I am still playing with your XSD classes. I think that I don't have
> to tell that I found them great.

Thanks, I am glad you like it.


> Not quite so easy to use, but when you get to known it flows smoothly.

Is it difficult to use before you've read the Getting Started Guide[1] or
after?

[1] http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/


> The thing is, now I am separting the interfaces on a dll, so I used
> the export option from the xsd generation. But, when some classes
> are freed, it throws an access violation. As these are hard to debug,
> I've starting decouping until I really isolated the problem. Basically
> I have one class like this:
>
> class __declspec(dllexport) ObligorID: public ::xml_schema::string

Do you really have __declspec(dllexport) there or is it some CPP macro
that changes from __declspec(dllexport) to __declspec(dllimport)?


> {
>   public:
>   // Constructors.
>   //
>   ObligorID ();
>
>   ObligorID (const ::xml_schema::string&);
>
>   ObligorID (const ::xercesc::DOMElement& e,
>              ::xml_schema::flags f = 0,
>              ::xml_schema::type* c = 0);
>
>   ObligorID (const ::xercesc::DOMAttr& a,
>              ::xml_schema::flags f = 0,
>              ::xml_schema::type* c = 0);
>
>   ObligorID (const ::std::string& s,
>              const ::xercesc::DOMElement* e,
>              ::xml_schema::flags f = 0,
>              ::xml_schema::type* c = 0);
>
>   ObligorID (const ObligorID& x,
>              ::xml_schema::flags f = 0,
>              ::xml_schema::type* c = 0);
>
>   virtual ObligorID*
>   _clone (::xml_schema::flags f = 0,
>           ::xml_schema::type* c = 0) const;
> };
>
> Which is fairly simple. On the executable where I call the dll, if I
> do a simple:
>
> 	ObligorID* obl = new ObligorID("131 xxxxxxxxxxxxxwxxxx");
> 	delete obl;
>
> As the first entries of the main, I get an exception on the delete.
> Do you have any idea where does this came from?

That's very strange. The usual suspect would be the cross-DLL memory
allocation/deallocation but here you create and delete the object in
main() so this can't be it. Just to confirm, can you change the
generated object code type in both your application and DLL to use
the DLL runtime and see if there is any change?

You may also want to step into the "delete obl" statement in the
debugger and see what's going on and where it crashes. Or you can
send me a small example that reproduces this problem and I will
take a look.


> Also, I am wondering why on the getters and setters of the classes
> sometimes you can simply pass a string (for the dates, for instance)
> and sometimes you mas pass an instantiated object from a string. Example:
>
> asset.MaturityDate("2005-01-01"); // Nice way of doing it
> asset.AssumedRecoveryLookup(AssumedRecoveryLookup("N")); // Why can't I just pass the "N"?

C++ does not allow chains of implicit conversions. In other words, if
you have class A that has an (implicit) constructor from const char*
and class B that has an (implicit) constructor from A and you have a
function f() with argument of type B, then you cannot pass "foo" to
it because that would require a chain of conversions:
const char*-> A -> B

In the above example, MaturityDate() has an argument which can be
implicitly constructed from a string literal while AssumedRecoveryLookup()
does not. Can you tell me what the AssumedRecoveryLookup schema type
looks like?

Boris


= = = = = = = = = = = = = = = = = = = = = = = = =
Fortis disclaimer :
http://www.fortis.be/legal/disclaimer.htm

Privacy policy related to banking activities of Fortis:
http://www.fortis.be/legal/privacy_policy.htm
= = = = = = = = = = = = = = = = = = = = = = = = =




From boris at codesynthesis.com  Wed Nov 14 07:04:27 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Re: Access Violation when deleting objects
In-Reply-To: <8E2E628CE354934FAB31A90699BCFA0D0248F34E@spmw0018.mail.shared.fortis>
References: <20071113115457.GH15207@karelia>
	<8E2E628CE354934FAB31A90699BCFA0D0248F34E@spmw0018.mail.shared.fortis>
Message-ID: <20071114120427.GB4852@karelia>

Hi Bruno,

bruno.marotta@fortis.com <bruno.marotta@fortis.com> writes:

> About the string question as you may see here bellow the
> AssumedRecoveryLookup is a pure and simple string class.
> And it is only used on the asset class. So, why must it
> be a class and just a simple property from the Asset with
> type xml_schema::string? Isn't the transformation adding
> too much code for nothing?

Well, your schema defines AssumedRecoveryLookup by inheriting
from xsd:string but without adding any attributes or elements
to it. If you want your AssumedRecoveryLookup attribute/element
to have xml_schema::string as a type, then use xsd:string in
your schema. In other words, XSD cannot read your mind and
figure out when you want a proper type generated and when you
want a base class to be used instead.

Having said that, we are going to add generation of an extra
constructor for types like AssumedRecoveryLookup so that you
can pass a string literal instead of explicitly constructing
and instance.

Boris


From bruno.marotta at fortis.com  Wed Nov 14 07:39:02 2007
From: bruno.marotta at fortis.com (bruno.marotta@fortis.com)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] RE: Access Violation when deleting objects
In-Reply-To: <20071114120427.GB4852@karelia>
Message-ID: <8E2E628CE354934FAB31A90699BCFA0D0248F356@spmw0018.mail.shared.fortis>

Hi Boris,

thanks again for the prompt replying, ant thanks again for spending your time with my requests. 

I think that the idea of having another contructor will be great. But it will be better to have an option for not creating empty classes like this one. For instance, my schema is something like this:

...
<xs:element name="Asset" maxOccurs="unbounded">
	<xs:complexType>
		<xs:sequence>
			<xs:element name="ObligorID">
				<xs:simpleType>
					<xs:restriction base="xs:string">
						<xs:minLength value="1"/>
						<xs:whiteSpace value="collapse"/>
					</xs:restriction>
				</xs:simpleType>
			</xs:element>
			...
 
How does XSD works today: 
	- Creates the Asset object, 
	- Creates the ObligorID object with some functions and no implemenation (only for clone), 
	- Creates the Asset::Obligor_ID type equals to ObligorID
	- Creates the getters and setters of Asset::ObligorID

What I am suggesting is to have an option --DoNotCreateClassForSimpleElements, meaning, if an element is just a string, a double or whatever type that can be easily mapped to one of the xml_schema basic types, have no childs and no enumeration restrictions, there is actual no need for creating a class with no implementation on it. 

How should XSD work when this option is on for the example above:
	- Creates the Asset object, 
	- Creates the Asset::Obligor_ID type equals to xml_schema::string
	- Creates the getters and setters of Asset::ObligorID

This will not only solve the bellow mentioned issue, but will also reduce a lot the size and complexity of the generated code.

What do you think?!

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Wednesday, November 14, 2007 1:04 PM
To: Marotta Bruno
Cc: xsd-users@codesynthesis.com
Subject: Re: Access Violation when deleting objects

Hi Bruno,

bruno.marotta@fortis.com <bruno.marotta@fortis.com> writes:

> About the string question as you may see here bellow the
> AssumedRecoveryLookup is a pure and simple string class.
> And it is only used on the asset class. So, why must it
> be a class and just a simple property from the Asset with
> type xml_schema::string? Isn't the transformation adding
> too much code for nothing?

Well, your schema defines AssumedRecoveryLookup by inheriting
from xsd:string but without adding any attributes or elements
to it. If you want your AssumedRecoveryLookup attribute/element
to have xml_schema::string as a type, then use xsd:string in
your schema. In other words, XSD cannot read your mind and
figure out when you want a proper type generated and when you
want a base class to be used instead.

Having said that, we are going to add generation of an extra
constructor for types like AssumedRecoveryLookup so that you
can pass a string literal instead of explicitly constructing
and instance.

Boris


= = = = = = = = = = = = = = = = = = = = = = = = =
Fortis disclaimer :
http://www.fortis.be/legal/disclaimer.htm

Privacy policy related to banking activities of Fortis:
http://www.fortis.be/legal/privacy_policy.htm
= = = = = = = = = = = = = = = = = = = = = = = = =




From wesm at filewood.snu.ac.kr  Wed Nov 14 07:19:39 2007
From: wesm at filewood.snu.ac.kr (Seungmin We)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] 'conflicting type' problem while compiling msml schema
Message-ID: <148EF2044EDF054DAB4DB2DA9C7C74E112AC2D@filewood-mail.filewood.snu.ac.kr>

Dear XSD-Users and CodeSynthesis,
 
I¡¯m trying to use XSD with MSML schema.
But I¡¯ve got some warnings and errors as followings.
I think it suffers from naming conflict.
Actually the schemas has name conflicted elements but the namespaces are different.
Why cannot XSD distinguish them?
Is there any way to resolve this problem?
 
Best Regards,
Seungmin We.
 
ps. for your convinience, I'm attaching the schema I used
 
 
 
[wesm@wesm-fedora msml-schema]$ xsd cxx-tree --generate-serialization --generate-doxygen msml.xsd
msml-conf-core-datatypes.xsd:198:33: warning: element 'visual' is implicitly of anyType
msml-conf-core-datatypes.xsd:198:33: info: did you forget to specify 'type' attribute?
msml-dialog-core-datatypes.xsd:50:46: warning: element 'control' is implicitly of anyType
msml-dialog-core-datatypes.xsd:50:46: info: did you forget to specify 'type' attribute?
synthesis-core.xsd:160:41: warning: element 'aws' is implicitly of anyType
synthesis-core.xsd:160:41: info: did you forget to specify 'type' attribute?
synthesis-core.xsd:173:45: warning: element 'struct' is implicitly of anyType
synthesis-core.xsd:173:45: info: did you forget to specify 'type' attribute?
msml-dialog-fax-sendrecv-datatypes.xsd:67:47: warning: element 'faxstart' is implicitly of anyType
msml-dialog-fax-sendrecv-datatypes.xsd:67:47: info: did you forget to specify 'type' attribute?
msml-dialog-fax-sendrecv-datatypes.xsd:68:51: warning: element 'faxnegotiate' is implicitly of anyType
msml-dialog-fax-sendrecv-datatypes.xsd:68:51: info: did you forget to specify 'type' attribute?
msml-dialog-fax-sendrecv-datatypes.xsd:69:50: warning: element 'faxpagedone' is implicitly of anyType
msml-dialog-fax-sendrecv-datatypes.xsd:69:50: info: did you forget to specify 'type' attribute?
msml-dialog-fax-sendrecv-datatypes.xsd:70:52: warning: element 'faxobjectdone' is implicitly of anyType
msml-dialog-fax-sendrecv-datatypes.xsd:70:52: info: did you forget to specify 'type' attribute?
msml-dialog-fax-sendrecv-datatypes.xsd:71:52: warning: element 'faxopcomplete' is implicitly of anyType
msml-dialog-fax-sendrecv-datatypes.xsd:71:52: info: did you forget to specify 'type' attribute?
msml-dialog-fax-sendrecv-datatypes.xsd:72:51: warning: element 'faxpollstart' is implicitly of anyType
msml-dialog-fax-sendrecv-datatypes.xsd:72:51: info: did you forget to specify 'type' attribute?
msml-audit-stream-datatypes.xsd:46:48: warning: element 'visual' is implicitly of anyType
msml-audit-stream-datatypes.xsd:46:48: info: did you forget to specify 'type' attribute?
msml-dialog-base-datatypes.xsd:14:69: error: element name 'play/audio' creates an unstable conflict when used as a type name
synthesis-core.xsd:260:44: info: conflicting type is defined here
msml-dialog-base-datatypes.xsd:14:69: info: use --anonymous-regex to resolve this conflict
msml-dialog-base-datatypes.xsd:14:69: info: and don't forget to pass the same option when translating 'msml-dialog-base-datatypes.xsd' and all the schemas that refer to it
msml-dialog-base-datatypes.xsd:51:69: error: element name 'play/media' creates an unstable conflict when used as a type name
msml-conf-core-datatypes.xsd:150:19: info: conflicting type is defined here
msml-dialog-base-datatypes.xsd:51:69: info: use --anonymous-regex to resolve this conflict
msml-dialog-base-datatypes.xsd:51:69: info: and don't forget to pass the same option when translating 'msml-dialog-base-datatypes.xsd' and all the schemas that refer to it
msml-dialog-base-datatypes.xsd:396:54: error: attribute name 'tone/duration' creates an unstable conflict when used as a type name
synthesis-core.xsd:27:33: info: conflicting type is defined here
msml-dialog-base-datatypes.xsd:396:54: info: use --anonymous-regex to resolve this conflict
msml-dialog-base-datatypes.xsd:396:54: info: and don't forget to pass the same option when translating 'msml-dialog-base-datatypes.xsd' and all the schemas that refer to it
msml-dialog-transform-datatypes.xsd:24:56: error: element name 'gain' creates an unstable conflict when used as a type name
msml-conf-core-datatypes.xsd:164:23: info: conflicting type is defined here
msml-dialog-transform-datatypes.xsd:24:56: info: use --anonymous-regex to resolve this conflict
msml-dialog-transform-datatypes.xsd:24:56: info: and don't forget to pass the same option when translating 'msml-dialog-transform-datatypes.xsd' and all the schemas that refer to it
msml-dialog-transform-datatypes.xsd:87:57: error: element name 'clamp' creates an unstable conflict when used as a type name
msml-conf-core-datatypes.xsd:193:23: info: conflicting type is defined here
msml-dialog-transform-datatypes.xsd:87:57: info: use --anonymous-regex to resolve this conflict
msml-dialog-transform-datatypes.xsd:87:57: info: and don't forget to pass the same option when translating 'msml-dialog-transform-datatypes.xsd' and all the schemas that refer to it
msml-dialog-transform-datatypes.xsd:51:49: error: attribute name 'agc/tgtlvl' creates an unstable conflict when used as a type name
msml-conf-core-datatypes.xsd:175:24: info: conflicting type is defined here
msml-dialog-transform-datatypes.xsd:51:49: info: use --anonymous-regex to resolve this conflict
msml-dialog-transform-datatypes.xsd:51:49: info: and don't forget to pass the same option when translating 'msml-dialog-transform-datatypes.xsd' and all the schemas that refer to it
msml-dialog-transform-datatypes.xsd:59:48: error: attribute name 'agc/maxgain' creates an unstable conflict when used as a type name
msml-conf-core-datatypes.xsd:183:24: info: conflicting type is defined here
msml-dialog-transform-datatypes.xsd:59:48: info: use --anonymous-regex to resolve this conflict
msml-dialog-transform-datatypes.xsd:59:48: info: and don't forget to pass the same option when translating 'msml-dialog-transform-datatypes.xsd' and all the schemas that refer to it
msml-dialog-transform-datatypes.xsd:75:50: error: attribute name 'gate/initial' creates an unstable conflict when used as a type name
msml-dialog-base-datatypes.xsd:114:22: info: conflicting type is defined here
msml-dialog-transform-datatypes.xsd:75:50: info: use --anonymous-regex to resolve this conflict
msml-dialog-transform-datatypes.xsd:75:50: info: and don't forget to pass the same option when translating 'msml-dialog-transform-datatypes.xsd' and all the schemas that refer to it
synthesis-core.xsd:272:48: error: attribute name 'emphasis/level' creates an unstable conflict when used as a type name
msml-dialog-base-datatypes.xsd:172:22: info: conflicting type is defined here
synthesis-core.xsd:272:48: info: use --anonymous-regex to resolve this conflict
synthesis-core.xsd:272:48: info: and don't forget to pass the same option when translating 'synthesis-core.xsd' and all the schemas that refer to it
synthesis-core.xsd:302:45: error: attribute name 'break/size' creates an unstable conflict when used as a type name
msml-conf-core-datatypes.xsd:364:19: info: conflicting type is defined here
synthesis-core.xsd:302:45: info: use --anonymous-regex to resolve this conflict
synthesis-core.xsd:302:45: info: and don't forget to pass the same option when translating 'synthesis-core.xsd' and all the schemas that refer to it
msml-audit-stream-datatypes.xsd:11:46: error: element name 'stream/clamp' creates an unstable conflict when used as a type name
msml-conf-core-datatypes.xsd:193:23: info: conflicting type is defined here
msml-audit-stream-datatypes.xsd:11:46: info: use --anonymous-regex to resolve this conflict
msml-audit-stream-datatypes.xsd:11:46: info: and don't forget to pass the same option when translating 'msml-audit-stream-datatypes.xsd' and all the schemas that refer to it
msml-audit-stream-datatypes.xsd:17:45: error: element name 'stream/gain' creates an unstable conflict when used as a type name
msml-conf-core-datatypes.xsd:164:23: info: conflicting type is defined here
msml-audit-stream-datatypes.xsd:17:45: info: use --anonymous-regex to resolve this conflict
msml-audit-stream-datatypes.xsd:17:45: info: and don't forget to pass the same option when translating 'msml-audit-stream-datatypes.xsd' and all the schemas that refer to it
msml-audit-stream-datatypes.xsd:50:48: error: attribute name 'stream/media' creates an unstable conflict when used as a type name
msml-conf-core-datatypes.xsd:150:19: info: conflicting type is defined here
msml-audit-stream-datatypes.xsd:50:48: info: use --anonymous-regex to resolve this conflict
msml-audit-stream-datatypes.xsd:50:48: info: and don't forget to pass the same option when translating 'msml-audit-stream-datatypes.xsd' and all the schemas that refer to it
msml-audit-stream-datatypes.xsd:58:46: error: attribute name 'stream/dir' creates an unstable conflict when used as a type name
msml-conf-core-datatypes.xsd:142:19: info: conflicting type is defined here
msml-audit-stream-datatypes.xsd:58:46: info: use --anonymous-regex to resolve this conflict
msml-audit-stream-datatypes.xsd:58:46: info: and don't forget to pass the same option when translating 'msml-audit-stream-datatypes.xsd' and all the schemas that refer to it
[wesm@wesm-fedora msml-schema]$

-------------- next part --------------
A non-text attachment was scrubbed...
Name: msml-schema.tar.gz
Type: application/x-gzip
Size: 14198 bytes
Desc: msml-schema.tar.gz
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071114/4a6e3752/msml-schema.tar.bin
From boris at codesynthesis.com  Wed Nov 14 09:57:17 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] 'conflicting type' problem while compiling msml schema
In-Reply-To: <148EF2044EDF054DAB4DB2DA9C7C74E112AC2D@filewood-mail.filewood.snu.ac.kr>
References: <148EF2044EDF054DAB4DB2DA9C7C74E112AC2D@filewood-mail.filewood.snu.ac.kr>
Message-ID: <20071114145717.GC5705@karelia>

Hi Seungmin,

[I am resending this email since the original one had an invalid
address for the xsd-users mailing list. Please reply to this post.]

Seungmin We <wesm@filewood.snu.ac.kr> writes:

> I think it suffers from naming conflict. Actually the schemas has name
> conflicted elements but the namespaces are different. Why cannot XSD
> distinguish them?

The conflicting names are actually all in the same (XML Schema) namespace.
The problem, the so-called unstable name conflict, is quite tricky and
this is the first real-world schema that I see exhibiting it. In a
nutshell, XSD tries to automatically name anonymous types and resolve
conflicts. It normally does a pretty good job, but there is one case
where it is impossible to resolve a conflict automatically. A simple
example of this situation is when, say both a.xsd and b.xsd have
anonymous types that XSD would name 'foo'. A third schema, d.xsd,
includes both a.xsd and b.xsd and thus triggers a name conflict.
The problem is that this conflict only exists when compiling schema
d.xsd and will go unnoticed when you translate a.xsd and b.xsd. This
is why it is called unstable conflict.

XSD allows you to resolve this by providing a custom name mapping
expression via the --anonymous-regex option (see the XSD Compiler
Command Line Manual for more information). I was able to compile
your schemas by using the following regex:

--anonymous-regex "#.*  (.+)/(.+)#$1_$2#"

(Use ' instead of " on Linux/UNIX.)

I've also added the --generate-polymorphic option since your schemas
use substitution groups.

There is unfortunately another problem: the grammar-code.xsd defines
a enumeration with one of the values being "NULL". By omission, the
XSD compiler does not have NULL in its reserved names table and as
a result the generated code does not compile. This problem will be
fixed in XSD 3.1.0. For the meantime, I can build you a pre-release
binary so you can compile your schemas. If you would like that, then
let me know which OS you are using.

Boris


From vinay.mogulothu at lehman.com  Wed Nov 14 20:37:25 2007
From: vinay.mogulothu at lehman.com (Mogulothu, Vinay K)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Custom get/set methods
Message-ID: <A51A68C32C649A4082EDC912A1EC254C0AA462B5@nypcmg1exms314.leh.lbcorp.lehman.com>


Hi

  The code generated from C++/tree has get/set methods with the
attribute name, we would like to provide the methods through
getAttribute, setAttribute for access
  From the three cardinality classes, the access methods for cardinality
one and sequence if we can add prefix get/set would work for us, for the
cardinality optional, do we have to write the get/set methods as
wrappers and access the underlying attribute using get() and set()

  Please advise how we could customize the code generation to achieve
this. 

  Regards
   Vinay
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

This message is intended only for the personal and confidential use of the designated recipient(s) named above.  If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited.  This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers.  Email transmission cannot be guaranteed to be secure or error-free.  Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such.  All information is subject to change without notice.

--------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.



From boris at codesynthesis.com  Thu Nov 15 08:26:45 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Custom get/set methods
In-Reply-To: <A51A68C32C649A4082EDC912A1EC254C0AA462B5@nypcmg1exms314.leh.lbcorp.lehman.com>
References: <A51A68C32C649A4082EDC912A1EC254C0AA462B5@nypcmg1exms314.leh.lbcorp.lehman.com>
Message-ID: <20071115132645.GG8290@karelia>

Hi Vinay,

Mogulothu, Vinay K <vinay.mogulothu@lehman.com> writes:

> The code generated from C++/tree has get/set methods with the
> attribute name, we would like to provide the methods through
> getAttribute, setAttribute for access

Do you want attribute accessor/modifier functions to be in the form
getFoo/setFoo where "Foo" is the name of the attribute -or- do you
want to have getAttribute("Foo")/setAttribute("Foo")?

> From the three cardinality classes, the access methods for cardinality
> one and sequence if we can add prefix get/set would work for us, for the
> cardinality optional, do we have to write the get/set methods as
> wrappers and access the underlying attribute using get() and set()

I guess you want to add the get/set prefixes to accessors/modifiers.
You can do it by customizing the generated types. That is, you can
instruct the XSD compiler to generate the normal mapping for XML
Schema types with different names and then you can inherit your
"wrapper" types from these generated types and implement the get/set
functions by calling the generated versions. For more information
on type customization see the C++/Tree Mapping Customization Guide:

http://wiki.codesynthesis.com/Tree/Customization_guide

As well as the examples in the examples/cxx/tree/custom/ directory.


This approach will work fine for small schemas where you have a handful
of types. For large vocabularies this will be a daunting task.

A feature that would allow changing the generated class/function names
has been requested before. I guess it would work fairly well for your
situation. We are still considering implementing this so let me know if
you are interested and we can see if we can make something for you
to try.

Boris


From vinay.mogulothu at lehman.com  Thu Nov 15 10:25:54 2007
From: vinay.mogulothu at lehman.com (Mogulothu, Vinay K)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Custom get/set methods
In-Reply-To: <20071115132645.GG8290@karelia>
References: <A51A68C32C649A4082EDC912A1EC254C0AA462B5@nypcmg1exms314.leh.lbcorp.lehman.com>
	<20071115132645.GG8290@karelia>
Message-ID: <A51A68C32C649A4082EDC912A1EC254C0AA462B6@nypcmg1exms314.leh.lbcorp.lehman.com>


Hi Boris,

  Thank you. We have looked at the option of customizing the generated
types, but as you mentioned it requires scripts to add the custom
wrappers for this option. We are interested in generating custom
class/function names. Please let us know if this feature is an easy
addition.

  Regards
   Vinay

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Thursday, November 15, 2007 8:27 AM
To: Mogulothu, Vinay K
Cc: xsd-users@codesynthesis.com; Janiv, Amnon
Subject: Re: [xsd-users] Custom get/set methods

Hi Vinay,

Mogulothu, Vinay K <vinay.mogulothu@lehman.com> writes:

> The code generated from C++/tree has get/set methods with the 
> attribute name, we would like to provide the methods through 
> getAttribute, setAttribute for access

Do you want attribute accessor/modifier functions to be in the form
getFoo/setFoo where "Foo" is the name of the attribute -or- do you want
to have getAttribute("Foo")/setAttribute("Foo")?

> From the three cardinality classes, the access methods for cardinality

> one and sequence if we can add prefix get/set would work for us, for 
> the cardinality optional, do we have to write the get/set methods as 
> wrappers and access the underlying attribute using get() and set()

I guess you want to add the get/set prefixes to accessors/modifiers.
You can do it by customizing the generated types. That is, you can
instruct the XSD compiler to generate the normal mapping for XML Schema
types with different names and then you can inherit your "wrapper" types
from these generated types and implement the get/set functions by
calling the generated versions. For more information on type
customization see the C++/Tree Mapping Customization Guide:

http://wiki.codesynthesis.com/Tree/Customization_guide

As well as the examples in the examples/cxx/tree/custom/ directory.


This approach will work fine for small schemas where you have a handful
of types. For large vocabularies this will be a daunting task.

A feature that would allow changing the generated class/function names
has been requested before. I guess it would work fairly well for your
situation. We are still considering implementing this so let me know if
you are interested and we can see if we can make something for you to
try.

Boris

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

This message is intended only for the personal and confidential use of the designated recipient(s) named above.  If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited.  This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers.  Email transmission cannot be guaranteed to be secure or error-free.  Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such.  All information is subject to change without notice.

--------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.




From Jan.Pauwels at graphicomp.com  Thu Nov 15 10:02:26 2007
From: Jan.Pauwels at graphicomp.com (Jan Pauwels)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] expected element 'http://www.opengis.net/gml#_Feature'
Message-ID: <16F6A48D762F9147828D29CF3EE6B36C086763@svr-db-01.DB-Net.local>

Hello,
 
I am new to XML, XML Schemas and XSD.
I have linked a executable 'driver9.exe' based on the example
'cxx/tree/hello".
When I run the executable on the file 'hello9.xml', I get the following
message "expected element 'http://www.opengis.net/gml#_Feature".
Can you tell me what should be changed on the file 'hello9.xml' in order
to run the executable ?
 
I am working on Windows XP.
I link with the static library.
I use Xerces 2.8.0.
The XSD-files and hello9.xml are attached.
 
 
Thank you in advance.
Greetings.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello9.zip
Type: application/x-zip-compressed
Size: 31742 bytes
Desc: hello9.zip
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071115/95d3630a/hello9.bin
From boris at codesynthesis.com  Thu Nov 15 12:48:04 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Custom get/set methods
In-Reply-To: <A51A68C32C649A4082EDC912A1EC254C0AA462B6@nypcmg1exms314.leh.lbcorp.lehman.com>
References: <A51A68C32C649A4082EDC912A1EC254C0AA462B5@nypcmg1exms314.leh.lbcorp.lehman.com>
	<20071115132645.GG8290@karelia>
	<A51A68C32C649A4082EDC912A1EC254C0AA462B6@nypcmg1exms314.leh.lbcorp.lehman.com>
Message-ID: <20071115174804.GJ8290@karelia>

Hi Vinay,

Mogulothu, Vinay K <vinay.mogulothu@lehman.com> writes:

>   Thank you. We have looked at the option of customizing the generated
> types, but as you mentioned it requires scripts to add the custom
> wrappers for this option. We are interested in generating custom
> class/function names. Please let us know if this feature is an easy
> addition.

It shouldn't be too difficult to add. The only concerns we have at the
moment are: (1) whether the regex approach will be able to handle all
desired transformations and (2) how to pass this information to the
compiler.

For (1), we need to make sure that we can support common naming
conventions, e.g., "lower case and underscore", "camel case",
"smalltalk", etc. Your case should be fairly easy to handle
since all you need to do is to add the 'get' or 'set' prefix
and capitalize the first letter of the original name.

For (2) we normally use command line options but depending on
how many expressions one may want to provide (right now it is
at least three: getter function, setter function, and class),
this could get messy. So will need to think about alternative
methods.

If anybody has any ideas or suggestions (Ray?), they will be
much appreciated.

I will give it some more thoughts and will try to implement this
idea next week. I should have a pre-release for you to try by
the end of next week.

Boris


From boris at codesynthesis.com  Thu Nov 15 12:57:03 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] expected element 'http://www.opengis.net/gml#_Feature'
In-Reply-To: <16F6A48D762F9147828D29CF3EE6B36C086763@svr-db-01.DB-Net.local>
References: <16F6A48D762F9147828D29CF3EE6B36C086763@svr-db-01.DB-Net.local>
Message-ID: <20071115175703.GK8290@karelia>

Hi Jan,

Jan Pauwels <Jan.Pauwels@graphicomp.com> writes:

> When I run the executable on the file 'hello9.xml', I get the following
> message "expected element 'http://www.opengis.net/gml#_Feature".
> Can you tell me what should be changed on the file 'hello9.xml' in order
> to run the executable ?

I am pretty sure you get this error because you haven't compiled
your schemas with the --generate-polymorphic option. GML uses
XML Schema polymorphism. In fact, the _Feature element is an
abstract root of a substitution group.

Recompiling all your schemas with --generate-polymorphic should
make it work.

For some additional information on compiling GML schemas with XSD,
see:

http://wiki.codesynthesis.com/Schemas/GML


Boris


From jnw at xs4all.nl  Thu Nov 15 15:04:57 2007
From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco])
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Custom get/set methods
Message-ID: <8868.194.109.230.85.1195157097.squirrel@webmail.xs4all.nl>

Hi Boris,

This is merely a thougth, but why not store all needed transformations in
a configuration file in XML? So xsd at least should not have any trouble
parsing it. :)

More specifically, a configuration file could contain one regex for
setters, one for getters, and one for whatever you like.

For instance:

<transformations>

    <transform function="getter" regex="/$([^ ])+/get\1/"/>

</transformations>

On second thought, you may even want to store equivalent of any command
line option in a configuration file.

Just my two cents ...

> Hi Vinay,
>
> Mogulothu, Vinay K <vinay.mogulothu@lehman.com> writes:
>
>>   Thank you. We have looked at the option of customizing the generated
>> types, but as you mentioned it requires scripts to add the custom
>> wrappers for this option. We are interested in generating custom
>> class/function names. Please let us know if this feature is an easy
>> addition.
>
> It shouldn't be too difficult to add. The only concerns we have at the
> moment are: (1) whether the regex approach will be able to handle all
> desired transformations and (2) how to pass this information to the
> compiler.
>
> For (1), we need to make sure that we can support common naming
> conventions, e.g., "lower case and underscore", "camel case",
> "smalltalk", etc. Your case should be fairly easy to handle
> since all you need to do is to add the 'get' or 'set' prefix
> and capitalize the first letter of the original name.
>
> For (2) we normally use command line options but depending on
> how many expressions one may want to provide (right now it is
> at least three: getter function, setter function, and class),
> this could get messy. So will need to think about alternative
> methods.
>
> If anybody has any ideas or suggestions (Ray?), they will be
> much appreciated.
>
> I will give it some more thoughts and will try to implement this
> idea next week. I should have a pre-release for you to try by
> the end of next week.
>
> Boris
>
>



From Henry_C.Ngu at lamresearch.com  Thu Nov 15 13:38:08 2007
From: Henry_C.Ngu at lamresearch.com (Ngu, Henry C)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Error while generating code from XSD
Message-ID: <252615686DDBA845977D9AF898D2F9770A61B845@pdtcexchmbx03.fremont.lamrc.net>

Hi:

    I am having error trying to generate h and c++ file from XSD file
(attached the zip file for your references)

 

----------------------------

xsd cxx-parser --namespace-map urn:semi-org:xsd.E132-1.V0305.auth=auth
--namespace-map urn:semi-org:xsd.CommonComponents.V0305.ccs=ccs
E134-1-V1105-Schema.xsd

E132CommonComponents-V0305-Schema.xsd:12:47: error: element name
'ErrorType/Exte

nsion' creates an unstable conflict when used as a type name

E134CommonComponents-V0305-Schema.xsd:13:21: info: conflicting type is
defined here

E132CommonComponents-V0305-Schema.xsd:12:47: info: use --anonymous-regex
to resolve this conflict

E132CommonComponents-V0305-Schema.xsd:12:47: info: and don't forget to
pass the

same option when translating 'E132CommonComponents-V0305-Schema.xsd' and
all the

 schemas that refer to it

--------------------------

 

Thanks

Henry

 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: E134001105.zip
Type: application/x-zip-compressed
Size: 13266 bytes
Desc: E134001105.zip
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071115/a2ddc6cd/E134001105.bin
From boris at codesynthesis.com  Thu Nov 15 15:49:20 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Error while generating code from XSD
In-Reply-To: <252615686DDBA845977D9AF898D2F9770A61B845@pdtcexchmbx03.fremont.lamrc.net>
References: <252615686DDBA845977D9AF898D2F9770A61B845@pdtcexchmbx03.fremont.lamrc.net>
Message-ID: <20071115204920.GL8290@karelia>

Hi Henry,

Ngu, Henry C <Henry_C.Ngu@lamresearch.com> writes:

> E132CommonComponents-V0305-Schema.xsd:12:47: error: element name
> 'ErrorType/Extension' creates an unstable conflict when used as a
> type name

For an overview of what this error means, please see:

http://www.codesynthesis.com/pipermail/xsd-users/2007-November/001333.html

In your case, however, this is triggered by two schema files with
identical target namespaces and content:

E132CommonComponents-V0305-Schema.xsd
E134CommonComponents-V0305-Schema.xsd

Essentially, one schema redefines a type definition from the other.
I suggest that you get rid of one of them and use the other in all
of your schemas.

Boris


From xunich at gmail.com  Fri Nov 16 02:20:43 2007
From: xunich at gmail.com (Nicholas Xu)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Question: root element in 'import' schema
Message-ID: <de841d8e0711152320j11d91c0rb0eef59549d2fbb4@mail.gmail.com>

Hello boris,

I met a problem when handling schema defined in RFC4745 and
draft-ietf-simple-presence-rules-10. RFC4745 defines schema of
common-policy :
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:common-policy"
elementFormDefault="qualified" attributeFormDefault="unqualified">
	<!-- /ruleset -->
	<xs:element name="ruleset">
		<xs:complexType>
			<xs:complexContent>
				<xs:restriction base="xs:anyType">
					<xs:sequence>
						<xs:element name="rule" type="cp:ruleType" minOccurs="0"
maxOccurs="unbounded"/>
					</xs:sequence>
				</xs:restriction>
			</xs:complexContent>
		</xs:complexType>
	</xs:element>
	<!-- /ruleset/rule -->
	<xs:complexType name="ruleType">
		<xs:complexContent>
			<xs:restriction base="xs:anyType">
				<xs:sequence>
					<xs:element name="conditions" type="cp:conditionsType" minOccurs="0"/>
					<xs:element name="actions" type="cp:extensibleType" minOccurs="0"/>
					<xs:element name="transformations" type="cp:extensibleType" minOccurs="0"/>
				</xs:sequence>
				<xs:attribute name="id" type="xs:ID" use="required"/>
			</xs:restriction>
		</xs:complexContent>
	</xs:complexType>
	<!-- //rule/conditions -->
	<xs:complexType name="conditionsType">
		<xs:complexContent>
			<xs:restriction base="xs:anyType">
				<xs:choice maxOccurs="unbounded">
					<xs:element name="identity" type="cp:identityType" minOccurs="0"/>
					<xs:element name="sphere" type="cp:sphereType" minOccurs="0"/>
					<xs:element name="validity" type="cp:validityType" minOccurs="0"/>
					<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
				</xs:choice>
			</xs:restriction>
		</xs:complexContent>
	</xs:complexType>
	<!-- //conditions/identity -->
	<xs:complexType name="identityType">
		<xs:complexContent>
			<xs:restriction base="xs:anyType">
				<xs:choice maxOccurs="unbounded">
					<xs:element name="one" type="cp:oneType"/>
					<xs:element name="many" type="cp:manyType"/>
					<xs:any namespace="##other" processContents="lax"/>
				</xs:choice>
			</xs:restriction>
		</xs:complexContent>
	</xs:complexType>
	<!-- //identity/one -->
	<xs:complexType name="oneType">
		<xs:complexContent>
			<xs:restriction base="xs:anyType">
				<xs:sequence>
					<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
				</xs:sequence>
				<xs:attribute name="id" type="xs:anyURI" use="required"/>
			</xs:restriction>
		</xs:complexContent>
	</xs:complexType>
	<!-- //identity/many -->
	<xs:complexType name="manyType">
		<xs:complexContent>
			<xs:restriction base="xs:anyType">
				<xs:choice minOccurs="0" maxOccurs="unbounded">
					<xs:element name="except" type="cp:exceptType"/>
					<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
				</xs:choice>
				<xs:attribute name="domain" type="xs:string" use="optional"/>
			</xs:restriction>
		</xs:complexContent>
	</xs:complexType>
	<!-- //many/except -->
	<xs:complexType name="exceptType">
		<xs:attribute name="domain" type="xs:string" use="optional"/>
		<xs:attribute name="id" type="xs:anyURI" use="optional"/>
	</xs:complexType>
	<!-- //conditions/sphere -->
	<xs:complexType name="sphereType">
		<xs:complexContent>
			<xs:restriction base="xs:anyType">
				<xs:attribute name="value" type="xs:string" use="required"/>
			</xs:restriction>
		</xs:complexContent>
	</xs:complexType>
	<!-- //conditions/validity -->
	<xs:complexType name="validityType">
		<xs:complexContent>
			<xs:restriction base="xs:anyType">
				<xs:sequence maxOccurs="unbounded">
					<xs:element name="from" type="xs:dateTime"/>
					<xs:element name="until" type="xs:dateTime"/>
				</xs:sequence>
			</xs:restriction>
		</xs:complexContent>
	</xs:complexType>
	<!-- //rule/actions or //rule/transformations -->
	<xs:complexType name="extensibleType">
		<xs:complexContent>
			<xs:restriction base="xs:anyType">
				<xs:sequence>
					<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
				</xs:sequence>
			</xs:restriction>
		</xs:complexContent>
	</xs:complexType>
</xs:schema>

draft-ietf-simple-presence-rules-10 defines pres-rules schema which
imports common-policy :
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:cr="urn:ietf:params:xml:ns:common-policy"
xmlns:pr="urn:ietf:params:xml:ns:pres-rules"
targetNamespace="urn:ietf:params:xml:ns:pres-rules"
elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:import namespace="urn:ietf:params:xml:ns:common-policy"
schemaLocation="common-policy.xsd"/>
	<xs:simpleType name="booleanPermission">
		<xs:restriction base="xs:boolean"/>
	</xs:simpleType>
	<xs:element name="service-uri-scheme" type="xs:token"/>
	<xs:element name="class" type="xs:token"/>
	<xs:element name="occurrence-id" type="xs:token"/>
	<xs:element name="service-uri" type="xs:anyURI"/>
	<xs:complexType name="provideServicePermission">
		<xs:choice>
			<xs:element name="all-services">
				<xs:complexType/>
			</xs:element>
			<xs:sequence minOccurs="0" maxOccurs="unbounded">
				<xs:choice>
					<xs:element ref="pr:service-uri"/>
					<xs:element ref="pr:service-uri-scheme"/>
					<xs:element ref="pr:occurrence-id"/>
					<xs:element ref="pr:class"/>
					<xs:any namespace="##other" processContents="lax"/>
				</xs:choice>
			</xs:sequence>
		</xs:choice>
	</xs:complexType>
	<xs:element name="provide-services" type="pr:provideServicePermission"/>
	<xs:element name="deviceID" type="xs:anyURI"/>
	<xs:complexType name="provideDevicePermission">
		<xs:choice>
			<xs:element name="all-devices">
				<xs:complexType/>
			</xs:element>
			<xs:sequence minOccurs="0" maxOccurs="unbounded">
				<xs:choice>
					<xs:element ref="pr:deviceID"/>
					<xs:element ref="pr:occurrence-id"/>
					<xs:element ref="pr:class"/>
					<xs:any namespace="##other" processContents="lax"/>
				</xs:choice>
			</xs:sequence>
		</xs:choice>
	</xs:complexType>
	<xs:element name="provide-devices" type="pr:provideDevicePermission"/>
	<xs:complexType name="providePersonPermission">
		<xs:choice>
			<xs:element name="all-persons">
				<xs:complexType/>
			</xs:element>
			<xs:sequence minOccurs="0" maxOccurs="unbounded">
				<xs:choice>
					<xs:element ref="pr:occurrence-id"/>
					<xs:element ref="pr:class"/>
					<xs:any namespace="##other" processContents="lax"/>
				</xs:choice>
			</xs:sequence>
		</xs:choice>
	</xs:complexType>
	<xs:element name="provide-persons" type="pr:providePersonPermission"/>
	<xs:element name="provide-activities" type="pr:booleanPermission"/>
	<xs:element name="provide-class" type="pr:booleanPermission"/>
	<xs:element name="provide-deviceID" type="pr:booleanPermission"/>
	<xs:element name="provide-mood" type="pr:booleanPermission"/>
	<xs:element name="provide-place-is" type="pr:booleanPermission"/>
	<xs:element name="provide-place-type" type="pr:booleanPermission"/>
	<xs:element name="provide-privacy" type="pr:booleanPermission"/>
	<xs:element name="provide-relationship" type="pr:booleanPermission"/>
	<xs:element name="provide-status-icon" type="pr:booleanPermission"/>
	<xs:element name="provide-sphere" type="pr:booleanPermission"/>
	<xs:element name="provide-time-offset" type="pr:booleanPermission"/>
	<xs:element name="provide-user-input">
		<xs:simpleType>
			<xs:restriction base="xs:string">
				<xs:enumeration value="false"/>
				<xs:enumeration value="bare"/>
				<xs:enumeration value="thresholds"/>
				<xs:enumeration value="full"/>
			</xs:restriction>
		</xs:simpleType>
	</xs:element>
	<xs:element name="provide-note" type="pr:booleanPermission"/>
	<xs:element name="sub-handling">
		<xs:simpleType>
			<xs:restriction base="xs:token">
				<xs:enumeration value="block"/>
				<xs:enumeration value="confirm"/>
				<xs:enumeration value="polite-block"/>
				<xs:enumeration value="allow"/>
			</xs:restriction>
		</xs:simpleType>
	</xs:element>
	<xs:complexType name="unknownBooleanPermission">
		<xs:simpleContent>
			<xs:extension base="pr:booleanPermission">
				<xs:attribute name="name" type="xs:string" use="required"/>
				<xs:attribute name="ns" type="xs:string" use="required"/>
			</xs:extension>
		</xs:simpleContent>
	</xs:complexType>
	<xs:element name="provide-unknown-attribute"
type="pr:unknownBooleanPermission"/>
	<xs:element name="provide-all-attributes">
		<xs:complexType/>
	</xs:element>
</xs:schema>

A example document is:
<?xml version="1.0" encoding="UTF-8"?>
   <cr:ruleset xmlns="urn:ietf:params:xml:ns:pres-rules"
    xmlns:pr="urn:ietf:params:xml:ns:pres-rules"
    xmlns:cr="urn:ietf:params:xml:ns:common-policy">
    <cr:rule id="a">
     <cr:conditions>
      <cr:identity>
       <cr:one id="sip:user@example.com"/>
      </cr:identity>
     </cr:conditions>
     <cr:actions>
      <pr:sub-handling>allow</pr:sub-handling>
     </cr:actions>
     <cr:transformations>
      <pr:provide-services>
        <pr:service-uri-scheme>sip</pr:service-uri-scheme>
        <pr:service-uri-scheme>mailto</pr:service-uri-scheme>
      </pr:provide-services>
      <pr:provide-persons>
        <pr:all-persons/>
      </pr:provide-persons>
      <pr:provide-activities>true</pr:provide-activities>
      <pr:provide-user-input>bare</pr:provide-user-input>
       <pr:provide-unknown-attribute
        ns="urn:vendor-specific:foo-namespace"
        name="foo">true</pr:provide-unknown-attribute>
     </cr:transformations>
    </cr:rule>
   </cr:ruleset>

You can see that the root element is from common-policy schema, but
some extentions is defined in pres-rules schema. I don't know how xsd
handles this situation. Would you give me some hints? Thanks a lot!

Best Regards,
Nich


From boris at codesynthesis.com  Fri Nov 16 02:50:39 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Question: root element in 'import' schema
In-Reply-To: <de841d8e0711152320j11d91c0rb0eef59549d2fbb4@mail.gmail.com>
References: <de841d8e0711152320j11d91c0rb0eef59549d2fbb4@mail.gmail.com>
Message-ID: <20071116075039.GB10985@karelia>

Hi Nicholas,

Nicholas Xu <xunich@gmail.com> writes:

> You can see that the root element is from common-policy schema, but
> some extentions is defined in pres-rules schema. I don't know how xsd
> handles this situation.

Your schemas use wildcard (xsd:any & xsd:anyAttribute) to provide
"extension points". You can request XSD to generate the wildcard
mapping with the --generate-wildcard option. The resulting code
will allow you to access the wildcard content as DOM fragments
(that is, a list of DOMElement's for xsd:any and DOMAttr's for
xsd:anyAttribute). See Section 2.12, "Mapping for any and
anyAttribute" in the C++/Tree Mapping User Manual:

http://codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.12

Once you get to the DOM content, you have two choices: you can
handle the data using the DOM API or, if you have schemas for the
data, parse the DOM fragments to obtain the corresponding object
model. Since you have the schema describing your "extension data",
you would probably want to use the latter approach. For an example
on how to do it see the 'wildcard' example in the examples/cxx/tree
directory.

Boris


From boris at codesynthesis.com  Fri Nov 16 07:34:51 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Custom get/set methods
In-Reply-To: <8868.194.109.230.85.1195157097.squirrel@webmail.xs4all.nl>
References: <8868.194.109.230.85.1195157097.squirrel@webmail.xs4all.nl>
Message-ID: <20071116123451.GC10985@karelia>

Hi Jeroen,

Jeroen N. Witmond [Bahco] <jnw@xs4all.nl> writes:

> This is merely a thougth, but why not store all needed transformations in
> a configuration file in XML? So xsd at least should not have any trouble
> parsing it. :)

Yes, and then we will need XSD to build XSD ;-)


> More specifically, a configuration file could contain one regex for
> setters, one for getters, and one for whatever you like.
>
> For instance:
>
> <transformations>
>
>     <transform function="getter" regex="/$([^ ])+/get\1/"/>
>
> </transformations>
>
> On second thought, you may even want to store equivalent of any command
> line option in a configuration file.

I think an XML-based format would be an overkill since there is not
much structure. Something like this should be enough:

--get-name-regex /$([^ ])+/get\u$1/
--set-name-regex /$([^ ])+/set\u$1/
--type-name-regex /$([^ ])+/\u$1/

The idea of allowing a set of options supplied in a file is a good
one and I've been thinking about it for a while now. Something along
these lines:

--options-file <file>

With the semantics being equivalent to specifying all the options
from <file> in place of the --options-file option.

Boris


From boris at codesynthesis.com  Fri Nov 16 09:59:30 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Re: Access Violation when deleting objects
In-Reply-To: <8E2E628CE354934FAB31A90699BCFA0D0248F356@spmw0018.mail.shared.fortis>
References: <20071114120427.GB4852@karelia>
	<8E2E628CE354934FAB31A90699BCFA0D0248F356@spmw0018.mail.shared.fortis>
Message-ID: <20071116145930.GA12083@karelia>

Hi Bruno,

bruno.marotta@fortis.com <bruno.marotta@fortis.com> writes:

> I think that the idea of having another contructor will be great. But
> it will be better to have an option for not creating empty classes
> like this one. For instance, my schema is something like this:
>
> ...
>	<xs:element name="ObligorID">
>		<xs:simpleType>
>			<xs:restriction base="xs:string">
>				<xs:minLength value="1"/>
>				<xs:whiteSpace value="collapse"/>
>			</xs:restriction>
>		</xs:simpleType>
>	</xs:element>

This type is not really empty: it includes a number of restrictions
which makes it not the same as xs:string. You are correct, right now
XSD generates an empty class for this. However, we are planning to add
support for restrictions as above so that they are enforced by the
generated types. Once we implement this, it won't make any sense
to have an option to treat it as an xs:string. So I think a c-tor
that allows you to initialize from a string literal has an advantage
of being a long-term solution.

Boris


From Jan.Pauwels at graphicomp.com  Fri Nov 16 08:05:21 2007
From: Jan.Pauwels at graphicomp.com (Jan Pauwels)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] retrieving data from gml:featureMember
Message-ID: <16F6A48D762F9147828D29CF3EE6B36C086765@svr-db-01.DB-Net.local>

Hello,
 
I am not so familiar with C++.
I want to retreive data from hello9.xml. (Extract from file follows)
 
  <gml:featureMember>
    <BP_Plan gml:id="obj_0">
   </BP_Plan>
 </gml:featureMember>
 
 
I use the following code : (copied from example polymorphism)
 
    auto_ptr<xplangml::XPlanAuszugType> Auszug (xplangml::XPlanAuszug
(argv[1]));
 
    xplangml::XPlanAuszugType copy (*Auszug); // Dynamic types are
preserved in copies.
 
    // Print what we've got.
    //
    for
(gml::AbstractFeatureCollectionType::featureMember_const_iterator i
(copy.featureMember().begin());
         i != copy.featureMember ().end ();
         ++i)
    {
      if (const xplangml::BP_PlanType* s = dynamic_cast<const
xplangml::BP_PlanType*> (&*i))
        cout << "BP_Plan" << endl;
      else
        cout << "no BP_Plan" << endl;
    }
 
The output is always "no BP_Plan".
featureMember can be BP_Plan, BP_... (lots of possible elements).
How can I retrieve data for element BP_Plan ?
Do I have to use an if-statement for each BP_ element that I want to
retrieve ?
   example :
         if (const xplangml::BP_PlanType* s = dynamic_cast<const
xplangml::BP_PlanType*> (&*i))
         else if (const xplangml::BP_BereichType* s = dynamic_cast<const
xplangml::BP_BereichType*> (&*i))

 
I attached the XML-files + schemas.
 
 
 
Thank you in advance.
 
Greetings.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello9.zip
Type: application/x-zip-compressed
Size: 31809 bytes
Desc: hello9.zip
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071116/c270857f/hello9.bin
From boris at codesynthesis.com  Fri Nov 16 10:16:51 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] retrieving data from gml:featureMember
In-Reply-To: <16F6A48D762F9147828D29CF3EE6B36C086765@svr-db-01.DB-Net.local>
References: <16F6A48D762F9147828D29CF3EE6B36C086765@svr-db-01.DB-Net.local>
Message-ID: <20071116151651.GB12083@karelia>

Hi Jan,

Jan Pauwels <Jan.Pauwels@graphicomp.com> writes:

>   <gml:featureMember>
>     <BP_Plan gml:id="obj_0">
>    </BP_Plan>
>  </gml:featureMember>
>
> I use the following code : (copied from example polymorphism)
>
> [...]
>
>     xplangml::XPlanAuszugType copy (*Auszug); // Dynamic types are
> preserved in copies.

You don't really need this: it makes a copy of the object model for
illustration.

>     for
> (gml::AbstractFeatureCollectionType::featureMember_const_iterator i
> (copy.featureMember().begin());
>          i != copy.featureMember ().end ();
>          ++i)
>     {
>       if (const xplangml::BP_PlanType* s = dynamic_cast<const
> xplangml::BP_PlanType*> (&*i))
>         cout << "BP_Plan" << endl;
>       else
>         cout << "no BP_Plan" << endl;

You are iterating over the sequence of the featureMember elements
and trying to cast them to BP_PlanType. But featureMember is not
a BP_PlanType, rather it contains an element of BP_PlanType. So
you need to go one level deeper:

const gml::FeaturePropertyType& fp = *i;

if (fp._Feature_present ())
{
  const gml::AbstractFeatureType& f = fp._Feature ();

  if (const xplangml::BP_PlanType* s = dynamic_cast<const
    xplangml::BP_PlanType*> (&f))
  {
    cout << "BP_Plan" << endl;
  }
  else
    cout << "no BP_Plan" << endl;
}

See the FeaturePropertyType type in GML's feature.xsd for more
information.

Boris


From boris at codesynthesis.com  Fri Nov 16 10:44:58 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] For <xs:restriction base="xs:anyType"> generated code
	does not compile.
In-Reply-To: <14113.194.109.230.85.1194557856.squirrel@webmail.xs4all.nl>
References: <14113.194.109.230.85.1194557856.squirrel@webmail.xs4all.nl>
Message-ID: <20071116154458.GC12083@karelia>

Hi Jeroen,

Sorry for replying so late.

Jeroen N. Witmond [Bahco] <jnw@xs4all.nl> writes:

> When I try to generate code for a Schema containing
> <xs:restriction base="xs:anyType">
> (my guess for the problem) it does not compile. The Schema file and
> Makefile attached demonstrate the problem.

You get this error because you use the --generate-xml-schema and
--extern-xml-schema options but do not compile the XmlSchema.hxx
header with --generate-ostream. This leads to a header file with
operator<<'s for built-in types not being included.

Boris


From jnw at xs4all.nl  Fri Nov 16 16:35:41 2007
From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco])
Date: Sun Oct 11 15:33:59 2009
Subject: Infinite recursion in generated code. (was: Re: [xsd-users] For 
	<xs:restriction base="xs:anyType"> generated code does not compile.)
Message-ID: <13733.194.109.230.85.1195248941.squirrel@webmail.xs4all.nl>

Hi Boris,

Boris Kolpackov writes:
> Hi Jeroen,
>
> Sorry for replying so late.

Don't worry about that. I have no deadlines regarding xsd. :)

> Jeroen N. Witmond [Bahco] <jnw@xs4all.nl> writes:
>
>> When I try to generate code for a Schema containing
>> <xs:restriction base="xs:anyType">
>> (my guess for the problem) it does not compile. The Schema file and
>> Makefile attached demonstrate the problem.
>
> You get this error because you use the --generate-xml-schema and
> --extern-xml-schema options but do not compile the XmlSchema.hxx
> header with --generate-ostream. This leads to a header file with
> operator<<'s for built-in types not being included.

Alright. But now I have come across the next stumbling block, and it is a
strange one.

When I add the custom type for anyType (for the xml:base attribute, from
item 4, custom-intended, on
http://www.xs4all.nl/~jnw/codesynthesis/xmlnamespace/index.html ) to the
translation of XmlSchema, and add a simple driver program, it enters an
infinite recursion starting at

    std::auto_ptr<metadox::problem>
      foo(metadox::problem_(argv1,
                            xml_schema::flags::keep_dom |
                            xml_schema::flags::dont_initialize));

At the start of the recursion, the backtrace is

#0  simple_type (this=0xafdfea9c, a=@0x8063908, f=
      {static keep_dom = 256, static own_dom = 512, static dont_validate =
<optimized out>, static dont_initialize = 1, static
no_xml_declaration = <optimized out>, static base = 16777216, x_ =
0}, c=0x0) at
/home/bahco/Sandbox/xsd-3.1.0.a1-i686-linux-gnu/libxsd/xsd/cxx/tree/parsing.txx:81

#1  0x08052033 in simple_type (this=0x805b2a0, a=@0x8063908, f=
      {static keep_dom = 256, static own_dom = 512, static dont_validate =
<optimized out>, static dont_initialize = 1, static
no_xml_declaration = <optimized out>, static base = 16777216, x_ =
769}, c=0x8077010) at
/home/bahco/Sandbox/xsd-3.1.0.a1-i686-linux-gnu/libxsd/xsd/cxx/tree/parsing.txx:82

#2  0x080521ad in uri (this=0x805b2a0, a=@0x8063908, f=
      {static keep_dom = 256, static own_dom = 512, static dont_validate =
<optimized out>, static dont_initialize = 1, static
no_xml_declaration = <optimized out>, static base = 16777216, x_ =
769}, c=0x8077010) at
/home/bahco/Sandbox/xsd-3.1.0.a1-i686-linux-gnu/libxsd/xsd/cxx/tree/parsing.txx:705

#3  0x0805227a in xsd::cxx::tree::traits<xsd::cxx::tree::uri<wchar_t,
xsd::cxx::tree::simple_type<xml_schema::XmlNamespace> >, wchar_t>::create
(
    a=@0x8063908, f=
      {static keep_dom = 256, static own_dom = 512, static dont_validate =
<optimized out>, static dont_initialize = 1, static
no_xml_declaration = <optimized out>, static base = 16777216, x_ =
769}, container=0x8077010) at
/home/bahco/Sandbox/xsd-3.1.0.a1-i686-linux-gnu/libxsd/xsd/cxx/tree/elements.hxx:717

#4  0x0804b06d in metadox::problem::parse (this=0x8077010, p=@0xafdfebd0, f=
      {static keep_dom = 256, static own_dom = 512, static dont_validate =
<optimized out>, static dont_initialize = 1, static
no_xml_declaration = <optimized out>, static base = 16777216, x_ =
769}) at restrict-base-anytype.cxx:131

#5  0x0804b3ac in problem (this=0x8077010, e=@0x8063480, f=
      {static keep_dom = 256, static own_dom = 512, static dont_validate =
<optimized out>, static dont_initialize = 1, static
no_xml_declaration = <optimized out>, static base = 16777216, x_ =
769}, c=0x0) at restrict-base-anytype.cxx:114

#6  0x0805232c in xsd::cxx::tree::traits<metadox::problem,
wchar_t>::create (e=@0x8063480, f=
      {static keep_dom = 256, static own_dom = 512, static dont_validate =
<optimized out>, static dont_initialize = 1, static
no_xml_declaration = <optimized out>, static base = 16777216, x_ =
769}, container=0x0) at
/home/bahco/Sandbox/xsd-3.1.0.a1-i686-linux-gnu/libxsd/xsd/cxx/tree/elements.hxx:711

#7  0x0804b548 in metadox::problem_ (d=0x8062d50, f=
      {static keep_dom = 256, static own_dom = 512, static dont_validate =
<optimized out>, static dont_initialize = 1, static
no_xml_declaration = <optimized out>, static base = 16777216, x_ =
769}) at restrict-base-anytype.cxx:458

#8  0x0804c9ee in metadox::problem_ (u=@0xafdfed60, f=
      {static keep_dom = 256, static own_dom = 512, static dont_validate =
<optimized out>, static dont_initialize = 1, static
no_xml_declaration = <optimized out>, static base = 16777216, x_ =
257}, p=@0xafdfed6c) at restrict-base-anytype.cxx:192

#9  0x0804aa98 in main (argc=2, argv=0xafdfee14) at driver.cpp:53

When the recursion causes a SIGSEGV, the backtrace is nothing but

#n  0x08051f9b in simple_type (this=0xaf60009c, a=@0x8063908, f=
      {static keep_dom = 256, static own_dom = 512, static dont_validate =
<optimized out>, static dont_initialize = 1, static
no_xml_declaration = <optimized out>, static base = 16777216, x_ =
0}, c=0x0) at
/home/bahco/Sandbox/xsd-3.1.0.a1-i686-linux-gnu/libxsd/xsd/cxx/tree/parsing.txx:82

for a very long time.

The strange thing is that the recursion appears only when I use the custom
anyType, and yet the backtrace above does not pass through code in any way
related to that custom type. And apart from the main program, it passes
only through generated code.

>From parsing.txx (version 3.1.0.a1):

      template <typename B>
      inline simple_type<B>::
      simple_type (const xercesc::DOMAttr& a, flags f, type* c)
          : B (a, f, c)                                      // line 82
      {
      }

Shouldn't the g++ compiler complain when this evaluates to a recursive
initialization? Or is the compiler generating incorrect code for this
case? Or am I completely out of my scope? :)

If you want the source files to recreate this problem, let me know and
I'll send them off the list.

Jeroen.




From boris at codesynthesis.com  Sat Nov 17 09:19:11 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: Infinite recursion in generated code. (was: Re: [xsd-users] For
	<xs:restriction base="xs:anyType"> generated code does not compile.)
In-Reply-To: <13733.194.109.230.85.1195248941.squirrel@webmail.xs4all.nl>
References: <13733.194.109.230.85.1195248941.squirrel@webmail.xs4all.nl>
Message-ID: <20071117141911.GA14521@karelia>

Hi Jeroen,

You get infinite recursion because you removed the required c-tor
with DOMAttr as first argument and added unnecessary c-tor with
simple_type as first argument. As a result, when a simple type is
constructed from DOMAttr in parsing.txx:82, the base type's c-tor
is called. While there is no constructor that takes DOMAttr, there
is one that takes simple_type. Implicit conversion is then used
and this continues forever.

You need to remove the c-tor with the simple_type argument and
add one with DOMAttr back.

Boris


From jnw at xs4all.nl  Sun Nov 18 04:16:33 2007
From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco])
Date: Sun Oct 11 15:33:59 2009
Subject: Infinite recursion in generated code. (was: Re: [xsd-users] 
	For <xs:restriction base="xs:anyType"> generated code does not 
	compile.)
Message-ID: <7303.194.109.230.85.1195377393.squirrel@webmail.xs4all.nl>

Hi Boris,

Boris Kolpackov wrote:
> Hi Jeroen,
>
> You get infinite recursion because you removed the required c-tor
> with DOMAttr as first argument and added unnecessary c-tor with
> simple_type as first argument. As a result, when a simple type is
> constructed from DOMAttr in parsing.txx:82, the base type's c-tor
> is called. While there is no constructor that takes DOMAttr, there
> is one that takes simple_type. Implicit conversion is then used
> and this continues forever.
>
> You need to remove the c-tor with the simple_type argument and
> add one with DOMAttr back.

Oops, my bad! The files used in the custom type were not really designed.
They evolved during my attemtps to get them to work. Implementating the
changes you give above made the infinite recursion disappear. (This did
require that I do a 'make clean'. Otherwise I still got an unresolved
external reference for the constructor taking simple_type.) I have merged
these changed into the files for the custom-intended implementation on
http://www.xs4all.nl/~jnw/codesynthesis/xmlnamespace/index.html

Is there an overview of which constructors are required for which kinds of
custom types? Or is there a way to get xsd to generate an overview? (I
noticed that in examples/cxx/tree the constructor taking DOMAttr is
generated only for custom/calendar.)

Thanks,

Jeroen.


From boris at codesynthesis.com  Sun Nov 18 09:51:03 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: Infinite recursion in generated code. (was: Re: [xsd-users] For
	<xs:restriction base="xs:anyType"> generated code does not compile.)
In-Reply-To: <7303.194.109.230.85.1195377393.squirrel@webmail.xs4all.nl>
References: <7303.194.109.230.85.1195377393.squirrel@webmail.xs4all.nl>
Message-ID: <20071118145103.GB18140@karelia>

Hi Jeroen,

Jeroen N. Witmond [Bahco] <jnw@xs4all.nl> writes:

> Is there an overview of which constructors are required for which kinds of
> custom types? Or is there a way to get xsd to generate an overview?

You should have at least the same set of constructors as the XSD-generated
version. If you are inheriting from the generated type then you can just
copy the c-tor signatures and change the class name.


> (I noticed that in examples/cxx/tree the constructor taking DOMAttr is
> generated only for custom/calendar.)

DOMAttr version is only generated for simple types. Having said that,
there are some c-tors missing in the examples and this will be fixed
in the next release.

Boris


From Jan.Pauwels at graphicomp.com  Mon Nov 19 07:38:07 2007
From: Jan.Pauwels at graphicomp.com (Jan Pauwels)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] retrieving polygon from raeumlicherGeltungsbereich
Message-ID: <16F6A48D762F9147828D29CF3EE6B36C086767@svr-db-01.DB-Net.local>

Hello,
 
I want to retreive a polygon from hello9.xml. (Extract from file
follows)

   <gml:featureMember>
    <BP_Plan gml:id="obj_0">
      <xplan:raeumlicherGeltungsbereich>
        <gml:Polygon>
          <gml:exterior>
            <gml:LinearRing>
              <gml:pos>-82.790 -117.603</gml:pos>
              <gml:pos>20.138 -113.254</gml:pos>
              <gml:pos>20.138 85.716</gml:pos>
              <gml:pos>-90.401 85.716</gml:pos>
              <gml:pos>-82.790 -117.603</gml:pos>
            </gml:LinearRing>
          </gml:exterior>
        </gml:Polygon>
      </xplan:raeumlicherGeltungsbereich>
    </BP_Plan>
  </gml:featureMember>

I use the following code :
 
      if (const xplangml::BP_PlanType* bplan = dynamic_cast<const
xplangml::BP_PlanType*> (&i->_Feature()))
      {
         cout << "BP_Plan" << endl;
 
         for
(xplangml::BP_PlanType::raeumlicherGeltungsbereich_const_iterator j
(bplan->raeumlicherGeltungsbereich().begin());
              j != bplan->raeumlicherGeltungsbereich().end();
              ++j)
         {
            ::gml::SurfacePropertyType surf = *j;
            ::gml::AbstractSurfaceType absurf = surf._Surface();
            ::gml::AbstractGMLType ab = absurf;
            if (const gml::PolygonType* p = dynamic_cast<const
gml::PolygonType*> (&absurf))
               cout << "polygon" << endl;
            else
               cout << "no polygon" << endl;
         }
    }

The output is always "no polygon".
 

I attached the XML-files + schemas.



Thank you in advance.

Greetings.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello9.zip
Type: application/x-zip-compressed
Size: 31954 bytes
Desc: hello9.zip
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071119/4391f7ea/hello9.bin
From boris at codesynthesis.com  Mon Nov 19 12:41:12 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] retrieving polygon from raeumlicherGeltungsbereich
In-Reply-To: <16F6A48D762F9147828D29CF3EE6B36C086767@svr-db-01.DB-Net.local>
References: <16F6A48D762F9147828D29CF3EE6B36C086767@svr-db-01.DB-Net.local>
Message-ID: <20071119174112.GA22184@karelia>

Hi Jan,

Jan Pauwels <Jan.Pauwels@graphicomp.com> writes:

>             ::gml::SurfacePropertyType surf = *j;
>             ::gml::AbstractSurfaceType absurf = surf._Surface();
>             ::gml::AbstractGMLType ab = absurf;

You need to use references instead of making copies:

gml::SurfacePropertyType& surf = *j;
gml::AbstractSurfaceType& absurf = surf._Surface();
gml::AbstractGMLType& ab = absurf;

When you make a copy using a copy constructor, you "slice" the object
and only get the statically-typed portion of it. This is why you
dynamic_cast fails.

Also note that this is a fairly basic C++ knowledge and we normally
don't help with such problems on this mailing list.

Boris


From rlischner at proteus-technologies.com  Tue Nov 20 13:19:48 2007
From: rlischner at proteus-technologies.com (Ray Lischner)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] How to preserve DOM when serializing?
Message-ID: <F1886AFB628EA94098943970F1563B89CA55CE@LINUS.proteus-technologies.com>

We have a node with mixed-content. We use the keep_dom flag when parsing the object to preserve the mixed-content nodes. The object is later copied as an element of a larger object. The larger object was constructed in C++ code, and lacks a DOM. We then want to serialize the larger object to a DOM; we want to keep the DOM for the inner element, but need to serialize all the other elements of the larger object.
 
The first solution that I can think of is to customize the inner class so its operator<<(DOMElement*) function copies the DOM instead of serializing the object.
 
Are there any other, better solutions?
--
Ray Lischner, Proteus Technologies

From boris at codesynthesis.com  Tue Nov 20 13:33:12 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] How to preserve DOM when serializing?
In-Reply-To: <F1886AFB628EA94098943970F1563B89CA55CE@LINUS.proteus-technologies.com>
References: <F1886AFB628EA94098943970F1563B89CA55CE@LINUS.proteus-technologies.com>
Message-ID: <20071120183312.GA29632@karelia>

Hi Ray,

Ray Lischner <rlischner@proteus-technologies.com> writes:

> We have a node with mixed-content. We use the keep_dom flag when parsing
> the object to preserve the mixed-content nodes. The object is later copied
> as an element of a larger object. The larger object was constructed in C++
> code, and lacks a DOM. We then want to serialize the larger object to a DOM;
> we want to keep the DOM for the inner element, but need to serialize all
> the other elements of the larger object.
>
> The first solution that I can think of is to customize the inner class so
> its operator<<(DOMElement*) function copies the DOM instead of serializing
> the object.

First of all, note that the DOM association is only maintained in
complete copies of the tree from the root node. This means that
when you copy the node into a larger object, your DOM association
will be gone.

There is a way to manually "associate" DOM to an object model that
was created programmatically (see the type::_node(DOMNode*) function).
However, this is a lot of trouble, especially if the object model is
big. An easier way, as you have suggested, is to customize the type
that needs to preserve its DOM content. But instead of using the
DOM association feature, I would simply store the DOM fragment
privately in this type within its own private DOMDocument. This
way you will customize the parsing c-tor to copy the DOM fragment
(importNode) into the private DOMDocument and the serialization
operator to copy the fragment into the output document. You will
also need to customize the copy c-tor to make proper copies of
the DOM fragment. This exact approach (private DOMDocument that
stores DOM fragments) is used in XSD 3.0.0 to handle wildcards.

Boris


From jnw at xs4all.nl  Tue Nov 20 14:00:10 2007
From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco])
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] cxx-parser: The generated test driver is silent.
Message-ID: <24108.194.109.230.85.1195585210.squirrel@webmail.xs4all.nl>

Hi Boris,

I'm afraid I've run into another problem related to anyType, in this case
in cxx-parser. When I generate code from anyType.xsd (attached), using xsd
options --generate-print-impl and --generate-test-driver, and run the
driver on file test.xml (attached), it produces no output. I expected "BB:
SomeID".

I've tried to debug this problem, and there seems to be a problem in file
anyType-pskel.cxx starting at line 81. In "bool
problem_pskel::_attribute_impl (const ::xml_schema::ro_string& ns, const
::xml_schema::ro_string& n, const ::xml_schema::ro_string& v)", the call
to "this->::xml_schema::any_type_pskel::_attribute_impl (ns, n, v)" always
returns true. (I ran into this problem while using more substantial xsd
and xml files. The attached files are a minimal testcase.)

I'm not surprised that ::xml_schema::any_type_pskel::_attribute_impl()
always returns true. But perhaps it should do it at the end of
problem_pskel::_attribute_impl. :)

Versions 3.0.0 and 3.1.0.a1 of xsd generate the same code for this xsd file.

Jeroen.

PS: I'll send the tarball containing the generated files to you privately
if you want.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: anyType.xsd
Type: application/octet-stream
Size: 439 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071120/4485c0d4/anyType.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.xml
Type: text/xml
Size: 183 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071120/4485c0d4/test.bin
From xunich at gmail.com  Wed Nov 21 03:50:05 2007
From: xunich at gmail.com (Nicholas Xu)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Handling part of an XML document
Message-ID: <de841d8e0711210050p55e379b6ve6c1a235e566961a@mail.gmail.com>

Hi Boris,

Can xsd support to parse or serialize part of an XML document (let's
say, a sub-element)? In some XML based protocol, such as XPath or
XCAP, only part of a complete XML document will be returned. Thank
you.

xunich


From boris at codesynthesis.com  Wed Nov 21 03:58:52 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:59 2009
Subject: [xsd-users] Handling part of an XML document
In-Reply-To: <de841d8e0711210050p55e379b6ve6c1a235e566961a@mail.gmail.com>
References: <de841d8e0711210050p55e379b6ve6c1a235e566961a@mail.gmail.com>
Message-ID: <20071121085852.GA1876@karelia>

Hi Nicholas,

Nicholas Xu <xunich@gmail.com> writes:

> Can xsd support to parse or serialize part of an XML document (let's
> say, a sub-element)?

Yes, you can parse/serialize XML fragments that correspond to individual
schema types. For that, however, you will need to set up the XML-to-DOM
(for parsing) and DOM-to-XML (for serialization) stages yourself. Then
you can instantiate an object model type from DOMElement or DOMAttr
as well as serialize an instance of an object model type to DOMElement
or DOMAttr.

For more details on how to implement this kind of parsing, see Q 2.4 and
2.5 in the C++/Tree Mapping FAQ[1] as well as the multiroot example in
examples/cxx/tree/.

For serialization, see Q 3.1 and 3.2 in the FAQ[1]. Once you have an
object model node and DOMElement, you can perform serialization by
using the serialization operator:

const SomeType& x = ... // Object model instance to serialize.
DOMElement& e = ... // DOM element to serialize to.

e << x;

[1] http://wiki.codesynthesis.com/Tree/FAQ


Boris


From thinkmega at gmail.com  Wed Nov 21 10:17:43 2007
From: thinkmega at gmail.com (Jeff Yu)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] dd xsd break IntelliSense?
Message-ID: <000001c82c51$a9f09ab0$fdd1d010$@com>

I came to realize the generated proxy class from the xsd might have caused
Microsoft's IntelliSense stop working.

 

Here is the code fragment:

 

int _tmain(int argc, _TCHAR* argv[])

{

      ::Block1 b11;

      ::Block2 b12;

      

// IntelliSense is working fine.

      xml_schema::string idp = "ID";

 

// That's it.  It stops working!

      

      b11.id(idp);

      

      

      RTable t(b11, b12);

      

}

 

Is the structure of the xsd proxy class the cause of the break?

 

Any feedback would be appreciated.

 

Thanks.

-------------- next part --------------
// Copyright (C) 2005-2007 Code Synthesis Tools CC
//
// This program was generated by CodeSynthesis XSD, an XML Schema to
// C++ data binding compiler.
//
// This program is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License version 2 as
// published by the Free Software Foundation.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
//
// In addition, as a special exception, Code Synthesis Tools CC gives
// permission to link this program with the Xerces-C++ library (or with
// modified versions of Xerces-C++ that use the same license as Xerces-C++),
// and distribute linked combinations including the two. You must obey
// the GNU General Public License version 2 in all respects for all of
// the code used other than Xerces-C++. If you modify this copy of the
// program, you may extend this exception to your version of the program,
// but you are not obligated to do so. If you do not wish to do so, delete
// this exception statement from your version.
//
// Furthermore, Code Synthesis Tools CC makes a special exception for
// the Free/Libre and Open Source Software (FLOSS) which is described
// in the accompanying FLOSSE file.
//

// Begin prologue.
//
//
// End prologue.
#include "stdafx.h"
#include <xsd/cxx/pre.hxx>

#include "RTable.hxx"

// RTable
// 

const RTable::Block1_type& RTable::
Block1 () const
{
  return this->Block1_.get ();
}

RTable::Block1_type& RTable::
Block1 ()
{
  return this->Block1_.get ();
}

void RTable::
Block1 (const Block1_type& Block1)
{
  this->Block1_.set (Block1);
}

void RTable::
Block1 (::std::auto_ptr< Block1_type > Block1)
{
  this->Block1_.set (Block1);
}

const RTable::Block2_type& RTable::
Block2 () const
{
  return this->Block2_.get ();
}

RTable::Block2_type& RTable::
Block2 ()
{
  return this->Block2_.get ();
}

void RTable::
Block2 (const Block2_type& Block2)
{
  this->Block2_.set (Block2);
}

void RTable::
Block2 (::std::auto_ptr< Block2_type > Block2)
{
  this->Block2_.set (Block2);
}


// Block1
// 

const Block1::kind_optional& Block1::
kind () const
{
  return this->kind_;
}

Block1::kind_optional& Block1::
kind ()
{
  return this->kind_;
}

void Block1::
kind (const kind_type& kind)
{
  this->kind_.set (kind);
}

void Block1::
kind (const kind_optional& kind)
{
  this->kind_ = kind;
}

void Block1::
kind (::std::auto_ptr< kind_type > kind)
{
  this->kind_.set (kind);
}

const Block1::id_optional& Block1::
id () const
{
  return this->id_;
}

Block1::id_optional& Block1::
id ()
{
  return this->id_;
}

void Block1::
id (const id_type& id)
{
  this->id_.set (id);
}

void Block1::
id (const id_optional& id)
{
  this->id_ = id;
}

void Block1::
id (::std::auto_ptr< id_type > id)
{
  this->id_.set (id);
}


// Block2
// 

const Block2::localhost_optional& Block2::
localhost () const
{
  return this->localhost_;
}

Block2::localhost_optional& Block2::
localhost ()
{
  return this->localhost_;
}

void Block2::
localhost (const localhost_type& localhost)
{
  this->localhost_.set (localhost);
}

void Block2::
localhost (const localhost_optional& localhost)
{
  this->localhost_ = localhost;
}

void Block2::
localhost (::std::auto_ptr< localhost_type > localhost)
{
  this->localhost_.set (localhost);
}

const Block2::ip_optional& Block2::
ip () const
{
  return this->ip_;
}

Block2::ip_optional& Block2::
ip ()
{
  return this->ip_;
}

void Block2::
ip (const ip_type& ip)
{
  this->ip_.set (ip);
}

void Block2::
ip (const ip_optional& ip)
{
  this->ip_ = ip;
}

void Block2::
ip (::std::auto_ptr< ip_type > ip)
{
  this->ip_.set (ip);
}


#include <xsd/cxx/xml/dom/parsing-source.hxx>

// RTable
//

RTable::
RTable (const Block1_type& Block1,
        const Block2_type& Block2)
: ::xml_schema::type (),
  Block1_ (Block1, ::xml_schema::flags (), this),
  Block2_ (Block2, ::xml_schema::flags (), this)
{
}

RTable::
RTable (const RTable& x,
        ::xml_schema::flags f,
        ::xml_schema::type* c)
: ::xml_schema::type (x, f, c),
  Block1_ (x.Block1_, f, this),
  Block2_ (x.Block2_, f, this)
{
}

RTable::
RTable (const ::xercesc::DOMElement& e,
        ::xml_schema::flags f,
        ::xml_schema::type* c)
: ::xml_schema::type (e, f | ::xml_schema::flags::base, c),
  Block1_ (f, this),
  Block2_ (f, this)
{
  if ((f & ::xml_schema::flags::base) == 0)
  {
    ::xsd::cxx::xml::dom::parser< char > p (e);
    this->parse (p, f);
  }
}

void RTable::
parse (::xsd::cxx::xml::dom::parser< char >& p,
       ::xml_schema::flags f)
{
  for (; p.more_elements (); p.next_element ())
  {
    const ::xercesc::DOMElement& i (p.cur_element ());
    const ::xsd::cxx::xml::qualified_name< char > n (
      ::xsd::cxx::xml::dom::name< char > (i));

    // Block1
    //
    if (n.name () == "Block1" && n.namespace_ ().empty ())
    {
      ::std::auto_ptr< Block1_type > r (
        Block1_traits::create (i, f, this));

      if (!Block1_.present ())
      {
        this->Block1 (r);
        continue;
      }
    }

    // Block2
    //
    if (n.name () == "Block2" && n.namespace_ ().empty ())
    {
      ::std::auto_ptr< Block2_type > r (
        Block2_traits::create (i, f, this));

      if (!Block2_.present ())
      {
        this->Block2 (r);
        continue;
      }
    }

    break;
  }

  if (!Block1_.present ())
  {
    throw ::xsd::cxx::tree::expected_element< char > (
      "Block1",
      "");
  }

  if (!Block2_.present ())
  {
    throw ::xsd::cxx::tree::expected_element< char > (
      "Block2",
      "");
  }
}

RTable* RTable::
_clone (::xml_schema::flags f,
        ::xml_schema::type* c) const
{
  return new RTable (*this, f, c);
}

// Block1
//

Block1::
Block1 ()
: ::xml_schema::type (),
  kind_ (::xml_schema::flags (), this),
  id_ (::xml_schema::flags (), this)
{
}

Block1::
Block1 (const Block1& x,
        ::xml_schema::flags f,
        ::xml_schema::type* c)
: ::xml_schema::type (x, f, c),
  kind_ (x.kind_, f, this),
  id_ (x.id_, f, this)
{
}

Block1::
Block1 (const ::xercesc::DOMElement& e,
        ::xml_schema::flags f,
        ::xml_schema::type* c)
: ::xml_schema::type (e, f | ::xml_schema::flags::base, c),
  kind_ (f, this),
  id_ (f, this)
{
  if ((f & ::xml_schema::flags::base) == 0)
  {
    ::xsd::cxx::xml::dom::parser< char > p (e);
    this->parse (p, f);
  }
}

void Block1::
parse (::xsd::cxx::xml::dom::parser< char >& p,
       ::xml_schema::flags f)
{
  while (p.more_attributes ())
  {
    const ::xercesc::DOMAttr& i (p.next_attribute ());
    const ::xsd::cxx::xml::qualified_name< char > n (
      ::xsd::cxx::xml::dom::name< char > (i));

    if (n.name () == "kind" && n.namespace_ ().empty ())
    {
      ::std::auto_ptr< kind_type > r (
        kind_traits::create (i, f, this));

      this->kind (r);
      continue;
    }

    if (n.name () == "id" && n.namespace_ ().empty ())
    {
      ::std::auto_ptr< id_type > r (
        id_traits::create (i, f, this));

      this->id (r);
      continue;
    }
  }
}

Block1* Block1::
_clone (::xml_schema::flags f,
        ::xml_schema::type* c) const
{
  return new Block1 (*this, f, c);
}

// Block2
//

Block2::
Block2 ()
: ::xml_schema::type (),
  localhost_ (::xml_schema::flags (), this),
  ip_ (::xml_schema::flags (), this)
{
}

Block2::
Block2 (const Block2& x,
        ::xml_schema::flags f,
        ::xml_schema::type* c)
: ::xml_schema::type (x, f, c),
  localhost_ (x.localhost_, f, this),
  ip_ (x.ip_, f, this)
{
}

Block2::
Block2 (const ::xercesc::DOMElement& e,
        ::xml_schema::flags f,
        ::xml_schema::type* c)
: ::xml_schema::type (e, f | ::xml_schema::flags::base, c),
  localhost_ (f, this),
  ip_ (f, this)
{
  if ((f & ::xml_schema::flags::base) == 0)
  {
    ::xsd::cxx::xml::dom::parser< char > p (e);
    this->parse (p, f);
  }
}

void Block2::
parse (::xsd::cxx::xml::dom::parser< char >& p,
       ::xml_schema::flags f)
{
  while (p.more_attributes ())
  {
    const ::xercesc::DOMAttr& i (p.next_attribute ());
    const ::xsd::cxx::xml::qualified_name< char > n (
      ::xsd::cxx::xml::dom::name< char > (i));

    if (n.name () == "localhost" && n.namespace_ ().empty ())
    {
      ::std::auto_ptr< localhost_type > r (
        localhost_traits::create (i, f, this));

      this->localhost (r);
      continue;
    }

    if (n.name () == "ip" && n.namespace_ ().empty ())
    {
      ::std::auto_ptr< ip_type > r (
        ip_traits::create (i, f, this));

      this->ip (r);
      continue;
    }
  }
}

Block2* Block2::
_clone (::xml_schema::flags f,
        ::xml_schema::type* c) const
{
  return new Block2 (*this, f, c);
}

#include <istream>
#include <xercesc/framework/Wrapper4InputSource.hpp>
#include <xsd/cxx/xml/sax/std-input-source.hxx>
#include <xsd/cxx/tree/error-handler.hxx>

::std::auto_ptr< ::RTable >
RTable_ (const ::std::string& u,
         ::xml_schema::flags f,
         const ::xml_schema::properties& p)
{
  ::xsd::cxx::xml::auto_initializer i (
    (f & ::xml_schema::flags::dont_initialize) == 0,
    (f & ::xml_schema::flags::keep_dom) == 0);

  ::xsd::cxx::tree::error_handler< char > h;

  ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > d (
    ::xsd::cxx::xml::dom::parse< char > (u, h, p, f));

  h.throw_if_failed< ::xsd::cxx::tree::parsing< char > > ();

  ::std::auto_ptr< ::RTable > r (
    ::RTable_ (
      d.get (), f | ::xml_schema::flags::own_dom, p));

  if (f & ::xml_schema::flags::keep_dom)
    d.release ();

  return r;
}

::std::auto_ptr< ::RTable >
RTable_ (const ::std::string& u,
         ::xml_schema::error_handler& h,
         ::xml_schema::flags f,
         const ::xml_schema::properties& p)
{
  ::xsd::cxx::xml::auto_initializer i (
    (f & ::xml_schema::flags::dont_initialize) == 0,
    (f & ::xml_schema::flags::keep_dom) == 0);

  ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > d (
    ::xsd::cxx::xml::dom::parse< char > (u, h, p, f));

  if (!d)
    throw ::xsd::cxx::tree::parsing< char > ();

  ::std::auto_ptr< ::RTable > r (
    ::RTable_ (
      d.get (), f | ::xml_schema::flags::own_dom, p));

  if (f & ::xml_schema::flags::keep_dom)
    d.release ();

  return r;
}

::std::auto_ptr< ::RTable >
RTable_ (const ::std::string& u,
         ::xercesc::DOMErrorHandler& h,
         ::xml_schema::flags f,
         const ::xml_schema::properties& p)
{
  ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > d (
    ::xsd::cxx::xml::dom::parse< char > (u, h, p, f));

  if (!d)
    throw ::xsd::cxx::tree::parsing< char > ();

  ::std::auto_ptr< ::RTable > r (
    ::RTable_ (
      d.get (), f | ::xml_schema::flags::own_dom, p));

  if (f & ::xml_schema::flags::keep_dom)
    d.release ();

  return r;
}

::std::auto_ptr< ::RTable >
RTable_ (::std::istream& is,
         ::xml_schema::flags f,
         const ::xml_schema::properties& p)
{
  ::xsd::cxx::xml::auto_initializer i (
    (f & ::xml_schema::flags::dont_initialize) == 0,
    (f & ::xml_schema::flags::keep_dom) == 0);

  ::xsd::cxx::xml::sax::std_input_source isrc (is);
  ::xercesc::Wrapper4InputSource wrap (&isrc, false);
  return ::RTable_ (wrap, f, p);
}

::std::auto_ptr< ::RTable >
RTable_ (::std::istream& is,
         ::xml_schema::error_handler& h,
         ::xml_schema::flags f,
         const ::xml_schema::properties& p)
{
  ::xsd::cxx::xml::auto_initializer i (
    (f & ::xml_schema::flags::dont_initialize) == 0,
    (f & ::xml_schema::flags::keep_dom) == 0);

  ::xsd::cxx::xml::sax::std_input_source isrc (is);
  ::xercesc::Wrapper4InputSource wrap (&isrc, false);
  return ::RTable_ (wrap, h, f, p);
}

::std::auto_ptr< ::RTable >
RTable_ (::std::istream& is,
         ::xercesc::DOMErrorHandler& h,
         ::xml_schema::flags f,
         const ::xml_schema::properties& p)
{
  ::xsd::cxx::xml::sax::std_input_source isrc (is);
  ::xercesc::Wrapper4InputSource wrap (&isrc, false);
  return ::RTable_ (wrap, h, f, p);
}

::std::auto_ptr< ::RTable >
RTable_ (::std::istream& is,
         const ::std::string& sid,
         ::xml_schema::flags f,
         const ::xml_schema::properties& p)
{
  ::xsd::cxx::xml::auto_initializer i (
    (f & ::xml_schema::flags::dont_initialize) == 0,
    (f & ::xml_schema::flags::keep_dom) == 0);

  ::xsd::cxx::xml::sax::std_input_source isrc (is, sid);
  ::xercesc::Wrapper4InputSource wrap (&isrc, false);
  return ::RTable_ (wrap, f, p);
}

::std::auto_ptr< ::RTable >
RTable_ (::std::istream& is,
         const ::std::string& sid,
         ::xml_schema::error_handler& h,
         ::xml_schema::flags f,
         const ::xml_schema::properties& p)
{
  ::xsd::cxx::xml::auto_initializer i (
    (f & ::xml_schema::flags::dont_initialize) == 0,
    (f & ::xml_schema::flags::keep_dom) == 0);

  ::xsd::cxx::xml::sax::std_input_source isrc (is, sid);
  ::xercesc::Wrapper4InputSource wrap (&isrc, false);
  return ::RTable_ (wrap, h, f, p);
}

::std::auto_ptr< ::RTable >
RTable_ (::std::istream& is,
         const ::std::string& sid,
         ::xercesc::DOMErrorHandler& h,
         ::xml_schema::flags f,
         const ::xml_schema::properties& p)
{
  ::xsd::cxx::xml::sax::std_input_source isrc (is, sid);
  ::xercesc::Wrapper4InputSource wrap (&isrc, false);
  return ::RTable_ (wrap, h, f, p);
}

::std::auto_ptr< ::RTable >
RTable_ (const ::xercesc::DOMInputSource& i,
         ::xml_schema::flags f,
         const ::xml_schema::properties& p)
{
  ::xsd::cxx::tree::error_handler< char > h;

  ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > d (
    ::xsd::cxx::xml::dom::parse< char > (i, h, p, f));

  h.throw_if_failed< ::xsd::cxx::tree::parsing< char > > ();

  ::std::auto_ptr< ::RTable > r (
    ::RTable_ (
      d.get (), f | ::xml_schema::flags::own_dom, p));

  if (f & ::xml_schema::flags::keep_dom)
    d.release ();

  return r;
}

::std::auto_ptr< ::RTable >
RTable_ (const ::xercesc::DOMInputSource& i,
         ::xml_schema::error_handler& h,
         ::xml_schema::flags f,
         const ::xml_schema::properties& p)
{
  ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > d (
    ::xsd::cxx::xml::dom::parse< char > (i, h, p, f));

  if (!d)
    throw ::xsd::cxx::tree::parsing< char > ();

  ::std::auto_ptr< ::RTable > r (
    ::RTable_ (
      d.get (), f | ::xml_schema::flags::own_dom, p));

  if (f & ::xml_schema::flags::keep_dom)
    d.release ();

  return r;
}

::std::auto_ptr< ::RTable >
RTable_ (const ::xercesc::DOMInputSource& i,
         ::xercesc::DOMErrorHandler& h,
         ::xml_schema::flags f,
         const ::xml_schema::properties& p)
{
  ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > d (
    ::xsd::cxx::xml::dom::parse< char > (i, h, p, f));

  if (!d)
    throw ::xsd::cxx::tree::parsing< char > ();

  ::std::auto_ptr< ::RTable > r (
    ::RTable_ (
      d.get (), f | ::xml_schema::flags::own_dom, p));

  if (f & ::xml_schema::flags::keep_dom)
    d.release ();

  return r;
}

::std::auto_ptr< ::RTable >
RTable_ (const ::xercesc::DOMDocument& d,
         ::xml_schema::flags f,
         const ::xml_schema::properties& p)
{
  if (f & ::xml_schema::flags::keep_dom)
  {
    ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > c (
      static_cast< ::xercesc::DOMDocument* > (d.cloneNode (true)));

    ::std::auto_ptr< ::RTable > r (
      ::RTable_ (
        c.get (), f | ::xml_schema::flags::own_dom, p));

    c.release ();
    return r;
  }

  const ::xercesc::DOMElement& e (*d.getDocumentElement ());
  const ::xsd::cxx::xml::qualified_name< char > n (
    ::xsd::cxx::xml::dom::name< char > (e));

  if (n.name () == "RTable" &&
      n.namespace_ () == "")
  {
    ::std::auto_ptr< ::RTable > r (
      ::xsd::cxx::tree::traits< ::RTable, char >::create (
        e, f, 0));
    return r;
  }

  throw ::xsd::cxx::tree::unexpected_element < char > (
    n.name (),
    n.namespace_ (),
    "RTable",
    "");
}

::std::auto_ptr< ::RTable >
RTable_ (::xercesc::DOMDocument* d,
         ::xml_schema::flags f,
         const ::xml_schema::properties&)
{
  ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > c (
    ((f & ::xml_schema::flags::keep_dom) &&
     !(f & ::xml_schema::flags::own_dom))
    ? static_cast< ::xercesc::DOMDocument* > (d->cloneNode (true))
    : 0);

  const ::xercesc::DOMElement& e (
    c.get ()
    ? *c->getDocumentElement ()
    : *d->getDocumentElement ());
  const ::xsd::cxx::xml::qualified_name< char > n (
    ::xsd::cxx::xml::dom::name< char > (e));

  if (n.name () == "RTable" &&
      n.namespace_ () == "")
  {
    ::std::auto_ptr< ::RTable > r (
      ::xsd::cxx::tree::traits< ::RTable, char >::create (
        e, f, 0));
    c.release ();
    return r;
  }

  throw ::xsd::cxx::tree::unexpected_element < char > (
    n.name (),
    n.namespace_ (),
    "RTable",
    "");
}

#include <ostream>
#include <xsd/cxx/xml/dom/serialization-source.hxx>
#include <xsd/cxx/tree/error-handler.hxx>

void
RTable_ (::std::ostream& o,
         const ::RTable& s,
         const ::xml_schema::namespace_infomap& m,
         const ::std::string& e,
         ::xml_schema::flags f)
{
  ::xsd::cxx::xml::auto_initializer i (
    (f & ::xml_schema::flags::dont_initialize) == 0);

  ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > d (
    ::RTable_ (s, m, f));

  ::xsd::cxx::tree::error_handler< char > h;

  ::xsd::cxx::xml::dom::ostream_format_target t (o);
  if (!::xsd::cxx::xml::dom::serialize (t, *d, e, h, f))
  {
    h.throw_if_failed< ::xsd::cxx::tree::serialization< char > > ();
  }
}

void
RTable_ (::std::ostream& o,
         const ::RTable& s,
         const ::xml_schema::namespace_infomap& m,
         ::xml_schema::error_handler& h,
         const ::std::string& e,
         ::xml_schema::flags f)
{
  ::xsd::cxx::xml::auto_initializer i (
    (f & ::xml_schema::flags::dont_initialize) == 0);

  ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > d (
    ::RTable_ (s, m, f));
  ::xsd::cxx::xml::dom::ostream_format_target t (o);
  if (!::xsd::cxx::xml::dom::serialize (t, *d, e, h, f))
  {
    throw ::xsd::cxx::tree::serialization< char > ();
  }
}

void
RTable_ (::std::ostream& o,
         const ::RTable& s,
         const ::xml_schema::namespace_infomap& m,
         ::xercesc::DOMErrorHandler& h,
         const ::std::string& e,
         ::xml_schema::flags f)
{
  ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > d (
    ::RTable_ (s, m, f));
  ::xsd::cxx::xml::dom::ostream_format_target t (o);
  if (!::xsd::cxx::xml::dom::serialize (t, *d, e, h, f))
  {
    throw ::xsd::cxx::tree::serialization< char > ();
  }
}

void
RTable_ (::xercesc::XMLFormatTarget& t,
         const ::RTable& s,
         const ::xml_schema::namespace_infomap& m,
         const ::std::string& e,
         ::xml_schema::flags f)
{
  ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > d (
    ::RTable_ (s, m, f));

  ::xsd::cxx::tree::error_handler< char > h;

  if (!::xsd::cxx::xml::dom::serialize (t, *d, e, h, f))
  {
    h.throw_if_failed< ::xsd::cxx::tree::serialization< char > > ();
  }
}

void
RTable_ (::xercesc::XMLFormatTarget& t,
         const ::RTable& s,
         const ::xml_schema::namespace_infomap& m,
         ::xml_schema::error_handler& h,
         const ::std::string& e,
         ::xml_schema::flags f)
{
  ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > d (
    ::RTable_ (s, m, f));
  if (!::xsd::cxx::xml::dom::serialize (t, *d, e, h, f))
  {
    throw ::xsd::cxx::tree::serialization< char > ();
  }
}

void
RTable_ (::xercesc::XMLFormatTarget& t,
         const ::RTable& s,
         const ::xml_schema::namespace_infomap& m,
         ::xercesc::DOMErrorHandler& h,
         const ::std::string& e,
         ::xml_schema::flags f)
{
  ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > d (
    ::RTable_ (s, m, f));
  if (!::xsd::cxx::xml::dom::serialize (t, *d, e, h, f))
  {
    throw ::xsd::cxx::tree::serialization< char > ();
  }
}

void
RTable_ (::xercesc::DOMDocument& d,
         const ::RTable& s,
         ::xml_schema::flags)
{
  ::xercesc::DOMElement& e (*d.getDocumentElement ());
  const ::xsd::cxx::xml::qualified_name< char > n (
    ::xsd::cxx::xml::dom::name< char > (e));

  if (n.name () == "RTable" &&
      n.namespace_ () == "")
  {
    e << s;
  }
  else
  {
    throw ::xsd::cxx::tree::unexpected_element < char > (
      n.name (),
      n.namespace_ (),
      "RTable",
      "");
  }
}

::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument >
RTable_ (const ::RTable& s,
         const ::xml_schema::namespace_infomap& m,
         ::xml_schema::flags f)
{
  try
  {
    ::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument > d (
      ::xsd::cxx::xml::dom::serialize< char > (
        "RTable",
        "",
        m, f));

    ::RTable_ (*d, s, f);
    return d;
  }
  catch (const ::xsd::cxx::xml::dom::mapping< char >& e)
  {
    throw ::xsd::cxx::tree::no_namespace_mapping< char > (e.name ());
  }
  catch (const ::xsd::cxx::xml::dom::xsi_already_in_use&)
  {
    throw ::xsd::cxx::tree::xsi_already_in_use< char > ();
  }
}

void
operator<< (::xercesc::DOMElement& e, const RTable& i)
{
  e << static_cast< const ::xml_schema::type& > (i);

  // Block1
  //
  {
    ::xercesc::DOMElement& s (
      ::xsd::cxx::xml::dom::create_element (
        "Block1",
        e));

    s << i.Block1 ();
  }

  // Block2
  //
  {
    ::xercesc::DOMElement& s (
      ::xsd::cxx::xml::dom::create_element (
        "Block2",
        e));

    s << i.Block2 ();
  }
}

void
operator<< (::xercesc::DOMElement& e, const Block1& i)
{
  e << static_cast< const ::xml_schema::type& > (i);

  // kind
  //
  if (i.kind ())
  {
    ::xercesc::DOMAttr& a (
      ::xsd::cxx::xml::dom::create_attribute (
        "kind",
        e));

    a << *i.kind ();
  }

  // id
  //
  if (i.id ())
  {
    ::xercesc::DOMAttr& a (
      ::xsd::cxx::xml::dom::create_attribute (
        "id",
        e));

    a << *i.id ();
  }
}

void
operator<< (::xercesc::DOMElement& e, const Block2& i)
{
  e << static_cast< const ::xml_schema::type& > (i);

  // localhost
  //
  if (i.localhost ())
  {
    ::xercesc::DOMAttr& a (
      ::xsd::cxx::xml::dom::create_attribute (
        "localhost",
        e));

    a << *i.localhost ();
  }

  // ip
  //
  if (i.ip ())
  {
    ::xercesc::DOMAttr& a (
      ::xsd::cxx::xml::dom::create_attribute (
        "ip",
        e));

    a << *i.ip ();
  }
}

#include <xsd/cxx/post.hxx>

// Begin epilogue.
//
//
// End epilogue.

-------------- next part --------------
// Copyright (C) 2005-2007 Code Synthesis Tools CC
//
// This program was generated by CodeSynthesis XSD, an XML Schema to
// C++ data binding compiler.
//
// This program is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License version 2 as
// published by the Free Software Foundation.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
//
// In addition, as a special exception, Code Synthesis Tools CC gives
// permission to link this program with the Xerces-C++ library (or with
// modified versions of Xerces-C++ that use the same license as Xerces-C++),
// and distribute linked combinations including the two. You must obey
// the GNU General Public License version 2 in all respects for all of
// the code used other than Xerces-C++. If you modify this copy of the
// program, you may extend this exception to your version of the program,
// but you are not obligated to do so. If you do not wish to do so, delete
// this exception statement from your version.
//
// Furthermore, Code Synthesis Tools CC makes a special exception for
// the Free/Libre and Open Source Software (FLOSS) which is described
// in the accompanying FLOSSE file.
//

#ifndef RTABLE_HXX
#define RTABLE_HXX

// Begin prologue.
//
//
// End prologue.

#include <xsd/cxx/version.hxx>

#if (XSD_INT_VERSION != 3000000L)
#error XSD runtime version mismatch
#endif

#include <xsd/cxx/pre.hxx>

#ifndef XSD_USE_CHAR
#define XSD_USE_CHAR
#endif

#ifndef XSD_CXX_TREE_USE_CHAR
#define XSD_CXX_TREE_USE_CHAR
#endif

#include <xsd/cxx/tree/exceptions.hxx>
#include <xsd/cxx/tree/elements.hxx>
#include <xsd/cxx/tree/types.hxx>

#include <xsd/cxx/xml/error-handler.hxx>

#include <xsd/cxx/tree/parsing.hxx>

#include <xsd/cxx/tree/serialization.hxx>
#include <xsd/cxx/xml/dom/serialization-header.hxx>

namespace xml_schema
{
  // anyType and anySimpleType.
  //
  typedef ::xsd::cxx::tree::type type;
  typedef ::xsd::cxx::tree::simple_type<type> simple_type;

  // 8-bit
  //
  typedef signed char byte;
  typedef unsigned char unsigned_byte;

  // 16-bit
  //
  typedef short short_;
  typedef unsigned short unsigned_short;

  // 32-bit
  //
  typedef int int_;
  typedef unsigned int unsigned_int;

  // 64-bit
  //
  typedef long long long_;
  typedef unsigned long long unsigned_long;

  // Supposed to be arbitrary-length integral types.
  //
  typedef long long integer;
  typedef integer non_positive_integer;
  typedef integer non_negative_integer;
  typedef integer positive_integer;
  typedef integer negative_integer;

  // Boolean.
  //
  typedef bool boolean;

  // Floating-point types.
  //
  typedef float float_;
  typedef double double_;
  typedef double decimal;

  // String types.
  //
  typedef ::xsd::cxx::tree::string< char, simple_type > string;
  typedef ::xsd::cxx::tree::normalized_string< char, string > normalized_string;
  typedef ::xsd::cxx::tree::token< char, normalized_string > token;
  typedef ::xsd::cxx::tree::name< char, token > name;
  typedef ::xsd::cxx::tree::nmtoken< char, token > nmtoken;
  typedef ::xsd::cxx::tree::nmtokens< char, simple_type, nmtoken> nmtokens;
  typedef ::xsd::cxx::tree::ncname< char, name > ncname;
  typedef ::xsd::cxx::tree::language< char, token > language;

  // ID/IDREF.
  //
  typedef ::xsd::cxx::tree::id< char, ncname > id;
  typedef ::xsd::cxx::tree::idref< type, char, ncname > idref;
  typedef ::xsd::cxx::tree::idrefs< char, simple_type, idref > idrefs;

  // URI.
  //
  typedef ::xsd::cxx::tree::uri< char, simple_type > uri;

  // Qualified name.
  //
  typedef ::xsd::cxx::tree::qname< char, simple_type, uri, ncname > qname;

  // Binary.
  //
  typedef ::xsd::cxx::tree::buffer< char > buffer;
  typedef ::xsd::cxx::tree::base64_binary< char, simple_type > base64_binary;
  typedef ::xsd::cxx::tree::hex_binary< char, simple_type > hex_binary;

  // Date/time.
  //
  typedef ::xsd::cxx::tree::date< char, simple_type > date;
  typedef ::xsd::cxx::tree::date_time< char, simple_type > date_time;
  typedef ::xsd::cxx::tree::duration< char, simple_type > duration;
  typedef ::xsd::cxx::tree::day< char, simple_type > day;
  typedef ::xsd::cxx::tree::month< char, simple_type > month;
  typedef ::xsd::cxx::tree::month_day< char, simple_type > month_day;
  typedef ::xsd::cxx::tree::year< char, simple_type > year;
  typedef ::xsd::cxx::tree::year_month< char, simple_type > year_month;
  typedef ::xsd::cxx::tree::time< char, simple_type > time;

  // Entity.
  //
  typedef ::xsd::cxx::tree::entity< char, ncname > entity;
  typedef ::xsd::cxx::tree::entities< char, simple_type, entity > entities;

  // Namespace information. Used in serialization functions.
  //
  typedef ::xsd::cxx::xml::dom::namespace_info < char > namespace_info;
  typedef ::xsd::cxx::xml::dom::namespace_infomap < char > namespace_infomap;

  // Flags and properties.
  //
  typedef ::xsd::cxx::tree::flags flags;
  typedef ::xsd::cxx::tree::properties< char > properties;

  // DOM user data key for back pointers to tree nodes.
  //
#ifndef XSD_CXX_TREE_TREE_NODE_KEY_IN___XML_SCHEMA
#define XSD_CXX_TREE_TREE_NODE_KEY_IN___XML_SCHEMA

  const XMLCh* const tree_node_key = ::xsd::cxx::tree::user_data_keys::node;

#endif

  // Exceptions.
  //
  typedef ::xsd::cxx::tree::exception< char > exception;
  typedef ::xsd::cxx::tree::parsing< char > parsing;
  typedef ::xsd::cxx::tree::expected_element< char > expected_element;
  typedef ::xsd::cxx::tree::unexpected_element< char > unexpected_element;
  typedef ::xsd::cxx::tree::expected_attribute< char > expected_attribute;
  typedef ::xsd::cxx::tree::unexpected_enumerator< char > unexpected_enumerator;
  typedef ::xsd::cxx::tree::expected_text_content< char > expected_text_content;
  typedef ::xsd::cxx::tree::no_type_info< char > no_type_info;
  typedef ::xsd::cxx::tree::not_derived< char > not_derived;
  typedef ::xsd::cxx::tree::duplicate_id< char > duplicate_id;
  typedef ::xsd::cxx::tree::serialization< char > serialization;
  typedef ::xsd::cxx::tree::no_namespace_mapping< char > no_namespace_mapping;
  typedef ::xsd::cxx::tree::no_prefix_mapping< char > no_prefix_mapping;
  typedef ::xsd::cxx::tree::xsi_already_in_use< char > xsi_already_in_use;
  typedef ::xsd::cxx::tree::bounds< char > bounds;

  // Parsing/serialization diagnostics.
  //
  typedef ::xsd::cxx::tree::severity severity;
  typedef ::xsd::cxx::tree::error< char > error;
  typedef ::xsd::cxx::tree::diagnostics< char > diagnostics;

  // Error handler interface.
  //
  typedef ::xsd::cxx::xml::error_handler< char > error_handler;
}

// Forward declarations.
//
class RTable;
class Block1;
class Block2;

#include <memory>    // std::auto_ptr
#include <algorithm> // std::binary_search

#include <xsd/cxx/tree/exceptions.hxx>
#include <xsd/cxx/tree/elements.hxx>
#include <xsd/cxx/tree/containers.hxx>
#include <xsd/cxx/tree/list.hxx>

#include <xsd/cxx/xml/dom/parsing-header.hxx>

class RTable: public ::xml_schema::type
{
  public:
  // Block1
  // 
  typedef ::Block1 Block1_type;
  typedef ::xsd::cxx::tree::traits< Block1_type, char > Block1_traits;

  const Block1_type&
  Block1 () const;

  Block1_type&
  Block1 ();

  void
  Block1 (const Block1_type& x);

  void
  Block1 (::std::auto_ptr< Block1_type > p);

  // Block2
  // 
  typedef ::Block2 Block2_type;
  typedef ::xsd::cxx::tree::traits< Block2_type, char > Block2_traits;

  const Block2_type&
  Block2 () const;

  Block2_type&
  Block2 ();

  void
  Block2 (const Block2_type& x);

  void
  Block2 (::std::auto_ptr< Block2_type > p);

  // Constructors.
  //
  RTable (const Block1_type&,
          const Block2_type&);

  RTable (const ::xercesc::DOMElement& e,
          ::xml_schema::flags f = 0,
          ::xml_schema::type* c = 0);

  RTable (const RTable& x,
          ::xml_schema::flags f = 0,
          ::xml_schema::type* c = 0);

  virtual RTable*
  _clone (::xml_schema::flags f = 0,
          ::xml_schema::type* c = 0) const;

  // Implementation.
  //
  protected:
  void
  parse (::xsd::cxx::xml::dom::parser< char >&,
         ::xml_schema::flags);

  private:
  ::xsd::cxx::tree::one< Block1_type > Block1_;
  ::xsd::cxx::tree::one< Block2_type > Block2_;
};

class Block1: public ::xml_schema::type
{
  public:
  // kind
  // 
  typedef ::xml_schema::string kind_type;
  typedef ::xsd::cxx::tree::optional< kind_type > kind_optional;
  typedef ::xsd::cxx::tree::traits< kind_type, char > kind_traits;

  const kind_optional&
  kind () const;

  kind_optional&
  kind ();

  void
  kind (const kind_type& x);

  void
  kind (const kind_optional& x);

  void
  kind (::std::auto_ptr< kind_type > p);

  // id
  // 
  typedef ::xml_schema::string id_type;
  typedef ::xsd::cxx::tree::optional< id_type > id_optional;
  typedef ::xsd::cxx::tree::traits< id_type, char > id_traits;

  const id_optional&
  id () const;

  id_optional&
  id ();

  void
  id (const id_type& x);

  void
  id (const id_optional& x);

  void
  id (::std::auto_ptr< id_type > p);

  // Constructors.
  //
  Block1 ();

  Block1 (const ::xercesc::DOMElement& e,
          ::xml_schema::flags f = 0,
          ::xml_schema::type* c = 0);

  Block1 (const Block1& x,
          ::xml_schema::flags f = 0,
          ::xml_schema::type* c = 0);

  virtual Block1*
  _clone (::xml_schema::flags f = 0,
          ::xml_schema::type* c = 0) const;

  // Implementation.
  //
  protected:
  void
  parse (::xsd::cxx::xml::dom::parser< char >&,
         ::xml_schema::flags);

  private:
  kind_optional kind_;
  id_optional id_;
};

class Block2: public ::xml_schema::type
{
  public:
  // localhost
  // 
  typedef ::xml_schema::string localhost_type;
  typedef ::xsd::cxx::tree::optional< localhost_type > localhost_optional;
  typedef ::xsd::cxx::tree::traits< localhost_type, char > localhost_traits;

  const localhost_optional&
  localhost () const;

  localhost_optional&
  localhost ();

  void
  localhost (const localhost_type& x);

  void
  localhost (const localhost_optional& x);

  void
  localhost (::std::auto_ptr< localhost_type > p);

  // ip
  // 
  typedef ::xml_schema::string ip_type;
  typedef ::xsd::cxx::tree::optional< ip_type > ip_optional;
  typedef ::xsd::cxx::tree::traits< ip_type, char > ip_traits;

  const ip_optional&
  ip () const;

  ip_optional&
  ip ();

  void
  ip (const ip_type& x);

  void
  ip (const ip_optional& x);

  void
  ip (::std::auto_ptr< ip_type > p);

  // Constructors.
  //
  Block2 ();

  Block2 (const ::xercesc::DOMElement& e,
          ::xml_schema::flags f = 0,
          ::xml_schema::type* c = 0);

  Block2 (const Block2& x,
          ::xml_schema::flags f = 0,
          ::xml_schema::type* c = 0);

  virtual Block2*
  _clone (::xml_schema::flags f = 0,
          ::xml_schema::type* c = 0) const;

  // Implementation.
  //
  protected:
  void
  parse (::xsd::cxx::xml::dom::parser< char >&,
         ::xml_schema::flags);

  private:
  localhost_optional localhost_;
  ip_optional ip_;
};

#include <iosfwd>

#include <xercesc/dom/DOMDocument.hpp>
#include <xercesc/dom/DOMInputSource.hpp>
#include <xercesc/dom/DOMErrorHandler.hpp>

// Parse a URI or a local file.
//

::std::auto_ptr< ::RTable >
RTable_ (const ::std::string& uri,
         ::xml_schema::flags f = 0,
         const ::xml_schema::properties& p = ::xml_schema::properties ());

::std::auto_ptr< ::RTable >
RTable_ (const ::std::string& uri,
         ::xml_schema::error_handler& eh,
         ::xml_schema::flags f = 0,
         const ::xml_schema::properties& p = ::xml_schema::properties ());

::std::auto_ptr< ::RTable >
RTable_ (const ::std::string& uri,
         ::xercesc::DOMErrorHandler& eh,
         ::xml_schema::flags f = 0,
         const ::xml_schema::properties& p = ::xml_schema::properties ());

// Parse std::istream.
//

::std::auto_ptr< ::RTable >
RTable_ (::std::istream& is,
         ::xml_schema::flags f = 0,
         const ::xml_schema::properties& p = ::xml_schema::properties ());

::std::auto_ptr< ::RTable >
RTable_ (::std::istream& is,
         ::xml_schema::error_handler& eh,
         ::xml_schema::flags f = 0,
         const ::xml_schema::properties& p = ::xml_schema::properties ());

::std::auto_ptr< ::RTable >
RTable_ (::std::istream& is,
         ::xercesc::DOMErrorHandler& eh,
         ::xml_schema::flags f = 0,
         const ::xml_schema::properties& p = ::xml_schema::properties ());

::std::auto_ptr< ::RTable >
RTable_ (::std::istream& is,
         const ::std::string& id,
         ::xml_schema::flags f = 0,
         const ::xml_schema::properties& p = ::xml_schema::properties ());

::std::auto_ptr< ::RTable >
RTable_ (::std::istream& is,
         const ::std::string& id,
         ::xml_schema::error_handler& eh,
         ::xml_schema::flags f = 0,
         const ::xml_schema::properties& p = ::xml_schema::properties ());

::std::auto_ptr< ::RTable >
RTable_ (::std::istream& is,
         const ::std::string& id,
         ::xercesc::DOMErrorHandler& eh,
         ::xml_schema::flags f = 0,
         const ::xml_schema::properties& p = ::xml_schema::properties ());

// Parse xercesc::DOMInputSource.
//

::std::auto_ptr< ::RTable >
RTable_ (const ::xercesc::DOMInputSource& is,
         ::xml_schema::flags f = 0,
         const ::xml_schema::properties& p = ::xml_schema::properties ());

::std::auto_ptr< ::RTable >
RTable_ (const ::xercesc::DOMInputSource& is,
         ::xml_schema::error_handler& eh,
         ::xml_schema::flags f = 0,
         const ::xml_schema::properties& p = ::xml_schema::properties ());

::std::auto_ptr< ::RTable >
RTable_ (const ::xercesc::DOMInputSource& is,
         ::xercesc::DOMErrorHandler& eh,
         ::xml_schema::flags f = 0,
         const ::xml_schema::properties& p = ::xml_schema::properties ());

// Parse xercesc::DOMDocument.
//

::std::auto_ptr< ::RTable >
RTable_ (const ::xercesc::DOMDocument& d,
         ::xml_schema::flags f = 0,
         const ::xml_schema::properties& p = ::xml_schema::properties ());

::std::auto_ptr< ::RTable >
RTable_ (::xercesc::DOMDocument* d,
         ::xml_schema::flags f = 0,
         const ::xml_schema::properties& p = ::xml_schema::properties ());

#include <iosfwd>

#include <xercesc/dom/DOMDocument.hpp>
#include <xercesc/dom/DOMErrorHandler.hpp>
#include <xercesc/framework/XMLFormatter.hpp>

#include <xsd/cxx/xml/dom/auto-ptr.hxx>

// Serialize to std::ostream.
//

void
RTable_ (::std::ostream& os,
         const ::RTable& x, 
         const ::xml_schema::namespace_infomap& m,
         const ::std::string& e = "UTF-8",
         ::xml_schema::flags f = 0);

void
RTable_ (::std::ostream& os,
         const ::RTable& x, 
         const ::xml_schema::namespace_infomap& m,
         ::xml_schema::error_handler& eh,
         const ::std::string& e = "UTF-8",
         ::xml_schema::flags f = 0);

void
RTable_ (::std::ostream& os,
         const ::RTable& x, 
         const ::xml_schema::namespace_infomap& m,
         ::xercesc::DOMErrorHandler& eh,
         const ::std::string& e = "UTF-8",
         ::xml_schema::flags f = 0);

// Serialize to xercesc::XMLFormatTarget.
//

void
RTable_ (::xercesc::XMLFormatTarget& ft,
         const ::RTable& x, 
         const ::xml_schema::namespace_infomap& m,
         const ::std::string& e = "UTF-8",
         ::xml_schema::flags f = 0);

void
RTable_ (::xercesc::XMLFormatTarget& ft,
         const ::RTable& x, 
         const ::xml_schema::namespace_infomap& m,
         ::xml_schema::error_handler& eh,
         const ::std::string& e = "UTF-8",
         ::xml_schema::flags f = 0);

void
RTable_ (::xercesc::XMLFormatTarget& ft,
         const ::RTable& x, 
         const ::xml_schema::namespace_infomap& m,
         ::xercesc::DOMErrorHandler& eh,
         const ::std::string& e = "UTF-8",
         ::xml_schema::flags f = 0);

// Serialize to an existing xercesc::DOMDocument.
//

void
RTable_ (::xercesc::DOMDocument& d,
         const ::RTable& x,
         ::xml_schema::flags f = 0);

// Serialize to a new xercesc::DOMDocument.
//

::xsd::cxx::xml::dom::auto_ptr< ::xercesc::DOMDocument >
RTable_ (const ::RTable& x, 
         const ::xml_schema::namespace_infomap& m,
         ::xml_schema::flags f = 0);

void
operator<< (::xercesc::DOMElement&, const RTable&);

void
operator<< (::xercesc::DOMElement&, const Block1&);

void
operator<< (::xercesc::DOMElement&, const Block2&);

#include <xsd/cxx/post.hxx>

// Begin epilogue.
//
//
// End epilogue.

#endif // RTABLE_HXX
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RTable.xsd
Type: application/xml
Size: 830 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071121/edfe6e14/RTable.xml
From boris at codesynthesis.com  Wed Nov 21 10:42:25 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] dd xsd break IntelliSense?
In-Reply-To: <000001c82c51$a9f09ab0$fdd1d010$@com>
References: <000001c82c51$a9f09ab0$fdd1d010$@com>
Message-ID: <20071121154225.GA7555@karelia>

Hi Jeff,

Jeff Yu <thinkmega@gmail.com> writes:

> Is the structure of the xsd proxy class the cause of the break?

No, it is buggy IntelliSense that is the cause of the break ;-).

Seriously, it is known that the generated code (or rather the
use of the generated code) can sometimes cause IntelliSense to
stop working. These situations are extremally bizarre and often
not reproducible on other installations. For example, I was
once tracking a problem that led to the following fragment
(parsing function declaration):

std::auto_ptr<Type>
root(::std::string, ....);

IntelliSense could recognize everything just before this declaration
and stopped recognizing anything right after it. The declaration is
perfectly valid C++. I tried to move things around I bit. As a result,
I found that the following incarnations worked fine with IntelliSense:

std::auto_ptr<Type>
root(std::string, ....);

std::auto_ptr<Type>
root( ::std::string, ....);

What can you do about something like this? This is just insane.

We've already done some work on the IntelliSense support for the
previous version and we plan to do some more work on simplifying
the runtime and the generated code for the next release. I am going
to keep your use-case in mind and will definitely take a look at it
when I work on this. Thanks for reporting it!

Also If you would like to try and track down the cause of this
problem -- let me know and I will give your some pointers on how
to isolate it.

Boris


From boris at codesynthesis.com  Wed Nov 21 16:38:12 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] Re: cxx-parser: The generated test driver is silent.
In-Reply-To: <24108.194.109.230.85.1195585210.squirrel@webmail.xs4all.nl>
References: <24108.194.109.230.85.1195585210.squirrel@webmail.xs4all.nl>
Message-ID: <20071121213812.GA8556@karelia>

Hi Jeroen,

Jeroen N. Witmond [Bahco] <jnw@xs4all.nl> writes:

> When I generate code from anyType.xsd (attached), using xsd
> options --generate-print-impl and --generate-test-driver, and run the
> driver on file test.xml (attached), it produces no output. I expected "BB:
> SomeID".

I can confirm this bug in 3.0.0. It also appears to be fixed in
my workspace. Thanks for reporting this and let me know if you
would like a pre-release binary.

Boris


From thinkmega at gmail.com  Wed Nov 21 17:02:01 2007
From: thinkmega at gmail.com (Jeff Yu)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] dd xsd break IntelliSense?
In-Reply-To: <20071121154225.GA7555@karelia>
References: <000001c82c51$a9f09ab0$fdd1d010$@com>
	<20071121154225.GA7555@karelia>
Message-ID: <000001c82c8a$24d0ecc0$6e72c640$@com>

Boris,

You are right.  IntelliSense is not stable.  I run into the same problem
with stl.  Any workaround you can recommend?

Thanks.
Jeff

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Wednesday, November 21, 2007 10:42 AM
To: Jeff Yu
Cc: xsd-users@codesynthesis.com
Subject: Re: [xsd-users] dd xsd break IntelliSense?

Hi Jeff,

Jeff Yu <thinkmega@gmail.com> writes:

> Is the structure of the xsd proxy class the cause of the break?

No, it is buggy IntelliSense that is the cause of the break ;-).

Seriously, it is known that the generated code (or rather the
use of the generated code) can sometimes cause IntelliSense to
stop working. These situations are extremally bizarre and often
not reproducible on other installations. For example, I was
once tracking a problem that led to the following fragment
(parsing function declaration):

std::auto_ptr<Type>
root(::std::string, ....);

IntelliSense could recognize everything just before this declaration
and stopped recognizing anything right after it. The declaration is
perfectly valid C++. I tried to move things around I bit. As a result,
I found that the following incarnations worked fine with IntelliSense:

std::auto_ptr<Type>
root(std::string, ....);

std::auto_ptr<Type>
root( ::std::string, ....);

What can you do about something like this? This is just insane.

We've already done some work on the IntelliSense support for the
previous version and we plan to do some more work on simplifying
the runtime and the generated code for the next release. I am going
to keep your use-case in mind and will definitely take a look at it
when I work on this. Thanks for reporting it!

Also If you would like to try and track down the cause of this
problem -- let me know and I will give your some pointers on how
to isolate it.

Boris


From boris at codesynthesis.com  Wed Nov 21 17:06:26 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] dd xsd break IntelliSense?
In-Reply-To: <000001c82c8a$24d0ecc0$6e72c640$@com>
References: <000001c82c51$a9f09ab0$fdd1d010$@com>
	<20071121154225.GA7555@karelia>
	<000001c82c8a$24d0ecc0$6e72c640$@com>
Message-ID: <20071121220626.GB8556@karelia>

Hi Jeff,

Jeff Yu <thinkmega@gmail.com> writes:

> You are right.  IntelliSense is not stable.  I run into the same problem
> with stl.  Any workaround you can recommend?

The only workaround that I can think of is to not rely on/disable
IntelliSense. I personally don't use Visual Studio for every day
development, so I cannot say for sure, but my feeling is that it
is virtually impossible to use IntelliSense in any serious C++
project that relies on modern C++ techniques.

BTW, If anyone has any experience to the contrary or has any tips
on how to keep IntelliSense functional in big code bases, I would
appreciate your comments!

>From our side, we will keep trying to make the generated code work
with IntelliSense as long as it does not compromise other aspects
of the code.

Boris


From kroiz at hyperroll.com  Thu Nov 22 02:21:40 2007
From: kroiz at hyperroll.com (Kroizman Guy)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] dd xsd break IntelliSense?
In-Reply-To: <20071121220626.GB8556@karelia>
References: <000001c82c51$a9f09ab0$fdd1d010$@com>
	<20071121154225.GA7555@karelia> <000001c82c8a$24d0ecc0$6e72c640$@com>
	<20071121220626.GB8556@karelia>
Message-ID: <1195716100.6462.1.camel@localhost.localdomain>

Some of my intelisense probelms resolved when I upgraded to the new/last
service pack in dev studio 2005.
That might work.

On Thu, 2007-11-22 at 00:06 +0200, Boris Kolpackov wrote:
> Hi Jeff,
> 
> Jeff Yu <thinkmega@gmail.com> writes:
> 
> > You are right.  IntelliSense is not stable.  I run into the same problem
> > with stl.  Any workaround you can recommend?
> 
> The only workaround that I can think of is to not rely on/disable
> IntelliSense. I personally don't use Visual Studio for every day
> development, so I cannot say for sure, but my feeling is that it
> is virtually impossible to use IntelliSense in any serious C++
> project that relies on modern C++ techniques.
> 
> BTW, If anyone has any experience to the contrary or has any tips
> on how to keep IntelliSense functional in big code bases, I would
> appreciate your comments!
> 
> >From our side, we will keep trying to make the generated code work
> with IntelliSense as long as it does not compromise other aspects
> of the code.
> 
> Boris
> 


From boris at codesynthesis.com  Fri Nov 23 02:56:44 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] Custom get/set methods
In-Reply-To: <A51A68C32C649A4082EDC912A1EC254C0AA462B6@nypcmg1exms314.leh.lbcorp.lehman.com>
References: <A51A68C32C649A4082EDC912A1EC254C0AA462B5@nypcmg1exms314.leh.lbcorp.lehman.com>
	<20071115132645.GG8290@karelia>
	<A51A68C32C649A4082EDC912A1EC254C0AA462B6@nypcmg1exms314.leh.lbcorp.lehman.com>
Message-ID: <20071123075644.GD29227@karelia>

Hi Vinay,

Mogulothu, Vinay K <vinay.mogulothu@lehman.com> writes:

> We are interested in generating custom class/function names. Please
> let us know if this feature is an easy addition.

Ok, support for customization of type/function names is ready. In
your case, all you will need to do is add '--function-naming java'
to the XSD command line.

This feature will be available in the next version of XSD. In the
meantime, I can build you a pre-release binary. If you would like
that, then let me know which platform(s) you need.

Boris


From vinay.mogulothu at lehman.com  Fri Nov 23 09:43:31 2007
From: vinay.mogulothu at lehman.com (Mogulothu, Vinay K)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] Custom get/set methods
In-Reply-To: <20071123075644.GD29227@karelia>
References: <A51A68C32C649A4082EDC912A1EC254C0AA462B5@nypcmg1exms314.leh.lbcorp.lehman.com>
	<20071115132645.GG8290@karelia>
	<A51A68C32C649A4082EDC912A1EC254C0AA462B6@nypcmg1exms314.leh.lbcorp.lehman.com>
	<20071123075644.GD29227@karelia>
Message-ID: <A51A68C32C649A4082EDC912A1EC254C0AA462F4@nypcmg1exms314.leh.lbcorp.lehman.com>


Hi Boris,

   Thank you.
   We are currently using Linux 2.4.21. 
   At present we are generating wrapper classes using perl scripts, but
we would like to try this customization feature, thank you.

   Regards
    Vinay

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Friday, November 23, 2007 2:57 AM
To: Mogulothu, Vinay K
Cc: Janiv, Amnon; xsd-users@codesynthesis.com
Subject: Re: [xsd-users] Custom get/set methods

Hi Vinay,

Mogulothu, Vinay K <vinay.mogulothu@lehman.com> writes:

> We are interested in generating custom class/function names. Please 
> let us know if this feature is an easy addition.

Ok, support for customization of type/function names is ready. In your
case, all you will need to do is add '--function-naming java'
to the XSD command line.

This feature will be available in the next version of XSD. In the
meantime, I can build you a pre-release binary. If you would like that,
then let me know which platform(s) you need.

Boris
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

This message is intended only for the personal and confidential use of the designated recipient(s) named above.  If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited.  This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers.  Email transmission cannot be guaranteed to be secure or error-free.  Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such.  All information is subject to change without notice.

--------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.




From mhoffm1060 at aol.com  Mon Nov 26 12:16:18 2007
From: mhoffm1060 at aol.com (mhoffm1060@aol.com)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] Attributes not found from imported schemas
Message-ID: <8C9FE67316F8D37-2520-425B@webmail-mf16.sysops.aol.com>


When I try to compile my schemas, I come across this error:

source/ext1.xsd:5:80: error: SimpleType (http://www.xyz.com/main/1.0.0:myValue) for attribute: myData1 not found
source/ext1.xsd:6:80: error: SimpleType (http://www.xyz.com/main/1.0.0:myValue) for attribute: myData2 not found
source/main.xsd:15:41: error: Invalid child 'attributeGroup' in the complex type

This seems to be similar to the issue mentioned in this thread:

http://www.codesynthesis.com/pipermail/xsd-users/2006-September/000538.html

The schemas are supplied to us from an outside source.? We could modify them as long as they are functionally equivalent, however we would prefer not to do this.

Am I doing something wrong during compilation to cause this error?

What?they are?trying to?do here is the schema in main.xsd is a released version, and the schema in ext1.xsd is an extension to the schema defined in main.xsd.? Is this a good way to do this or is there a more preferable way?? We have some input to the outside source of these schemas, so if there is a better way to extend the main schema they might be open to it.

Thanks,
Mark Hoffmann

The schemas are located in testcase/XSD/source directory of the attached file
The makefile is?located at testcase/XSD.? ( The environment variable XSD must be defined to the top level XSD directory before running "make all" )


________________________________________________________________________
Email and AIM finally together. You've gotta check out free AOL Mail! - http://mail.aol.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xsdTestCase.tar.gz
Type: application/x-gzip
Size: 1305 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071126/bb634313/xsdTestCase.tar.bin
From boris at codesynthesis.com  Mon Nov 26 15:50:36 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] Attributes not found from imported schemas
In-Reply-To: <8C9FE67316F8D37-2520-425B@webmail-mf16.sysops.aol.com>
References: <8C9FE67316F8D37-2520-425B@webmail-mf16.sysops.aol.com>
Message-ID: <20071126205036.GC21025@karelia>

Hi Mark,

mhoffm1060@aol.com <mhoffm1060@aol.com> writes:

> What they are trying to do here is the schema in main.xsd is a released
> version, and the schema in ext1.xsd is an extension to the schema defined
> in main.xsd. Is this a good way to do this or is there a more preferable
> way? We have some input to the outside source of these schemas, so if
> there is a better way to extend the main schema they might be open to it.

The problem is not really in the structure of your schemas but rather
in how you import them. When you import a schema, you specify the
schema namespace which XML Schema processors use as a key in a map
of grammars. One use for this map is to determine if a grammar for
a particular namespace has already been parsed. In other words,
when a schema processor sees an xs:import declaration, it checks
if there is already an entry in the grammar map and if so, the
import declaration is ignored.

One consequence of this approach is that if you have a first import
declaration (as seen by the processor) that specifies one schema
file and then a second import declaration which specifies a different
file with additional types and/or elements, then this second schema
file and all extra declaration in it will be ignored. This is why it
is advised to always import declaration for a particular XML vocabulary
using the same, top-level schema file.

In your case here is what happens when main.xsd is compiled: when
main.xsd is opened, the 'main' namespace is entered into the map.
Then ext1.xsd (imported from main.xsd) is processed. This file
contains an import declaration for the same 'main' namespaces
by with a different schema file: myIncludes.xsd. Since this
namespace is already known, myIncludes.xsd and all declarations
in it are ignored. This results in the error you observe.

The proper way to fix this is to import the 'main' namespace with
the same schema file (main.xsd) everywhere. That means changing
ext1.xsd to import main.xsd instead of myIncludes.xsd. While this
will work, the resulting schemas will have a cyclic dependency:
main.xsd needs Data from ext1.xsd and ext1.xsd needs myValue from
myIncludes.xsd via main.xsd. The generated C++ code for such a cycle
will work as long as there is no type inheritance involved. One
way to address this cyclic dependency would be to put all three
schemas in the same namespace and use the original inclusion
graph: main.xsd->ext1.xsd ext1.xsd->myInclude.xsd.

Another approach that will work in this particular case would be
to reorder the import and include declaration in main.xsd so that
types in myIncludes.xsd are declared before ext1.xsd is processed.

Boris


From mhoffm1060 at aol.com  Mon Nov 26 18:05:16 2007
From: mhoffm1060 at aol.com (mhoffm1060@aol.com)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] Attributes not found from imported schemas
In-Reply-To: <20071126205036.GC21025@karelia>
References: <8C9FE67316F8D37-2520-425B@webmail-mf16.sysops.aol.com>
	<20071126205036.GC21025@karelia>
Message-ID: <8C9FE97F1972A57-2574-46C@webmail-mf16.sysops.aol.com>

Boris,
Thank you for your quick and informative response.? 

Another question if I may: ?is this usual in the XML world ( to ignore additional imports of the same namespace )?? I was reading the spec ( http://www.w3.org/TR/xmlschema-1/#composition-schemaImport?see Note an the end of section: 4.2.3 References to schema components across namespaces?), and while the spec allows this, it mentions that this is risky behavior.

I'm asking because the entity that we receive these schema from declare that they are compliant to the above spec.? ( Apparently they are ), but if it is an industry practice to ignore the later imports, I'll have some leverage to get them to change the structure.

( I understand that by reorganizing the schemas I can get it to work.? However this is not a static schema and will be expanded this way on a periodic basis.? Therefore I would have to apply the modifications every time a new schema comes out, instead of getting it ready to use. )

Thanks,
Mark


-----Original Message-----
From: Boris Kolpackov <boris@codesynthesis.com>
To: mhoffm1060@aol.com
Cc: xsd-users@codesynthesis.com
Sent: Mon, 26 Nov 2007 12:50 pm
Subject: Re: [xsd-users] Attributes not found from imported schemas



Hi Mark,

mhoffm1060@aol.com <mhoffm1060@aol.com> writes:

> What they are trying to do here is the schema in main.xsd is a released
> version, and the schema in ext1.xsd is an extension to the schema defined
> in main.xsd. Is this a good way to do this or is there a more preferable
> way? We have some input to the outside source of these schemas, so if
> there is a better way to extend the main schema they might be open to it.

The problem is not really in the structure of your schemas but rather
in how you import them. When you import a schema, you specify the
schema namespace which XML Schema processors use as a key in a map
of grammars. One use for this map is to determine if a grammar for
a particular namespace has already been parsed. In other words,
when a schema processor sees an xs:import declaration, it checks
if there is already an entry in the grammar map and if so, the
import declaration is ignored.

One consequence of this approach is that if you have a first import
declaration (as seen by the processor) that specifies one schema
file and then a second import declaration which specifies a different
file with additional types and/or elements, then this second schema
file and all extra declaration in it will be ignored. This is why it
is advised to always import declaration for a particular XML vocabulary
using the same, top-level schema file.

In your case here is what happens when main.xsd is compiled: when
main.xsd is opened, the 'main' namespace is entered into the map.
Then ext1.xsd (imported from main.xsd) is processed. This file
contains an import declaration for the same 'main' namespaces
by with a different schema file: myIncludes.xsd. Since this
namespace is already known, myIncludes.xsd and all declarations
in it are ignored. This results in the error you observe.

The proper way to fix this is to import the 'main' namespace with
the same schema file (main.xsd) everywhere. That means changing
ext1.xsd to import main.xsd instead of myIncludes.xsd. While this
will work, the resulting schemas will have a cyclic dependency:
main.xsd needs Data from ext1.xsd and ext1.xsd needs myValue from
myIncludes.xsd via main.xsd. The generated C++ code for such a cycle
will work as long as there is no type inheritance involved. One
way to address this cyclic dependency would be to put all three
schemas in the same namespace and use the original inclusion
graph: main.xsd->ext1.xsd ext1.xsd->myInclude.xsd.

Another approach that will work in this particular case would be
to reorder the import and include declaration in main.xsd so that
types in myIncludes.xsd are declared before ext1.xsd is processed.

Boris


________________________________________________________________________
Email and AIM finally together. You've gotta check out free AOL Mail! - http://mail.aol.com

From boris at codesynthesis.com  Tue Nov 27 05:04:42 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] Attributes not found from imported schemas
In-Reply-To: <8C9FE97F1972A57-2574-46C@webmail-mf16.sysops.aol.com>
References: <8C9FE67316F8D37-2520-425B@webmail-mf16.sysops.aol.com>
	<20071126205036.GC21025@karelia>
	<8C9FE97F1972A57-2574-46C@webmail-mf16.sysops.aol.com>
Message-ID: <20071127100442.GC23335@karelia>

Hi Mark,

mhoffm1060@aol.com <mhoffm1060@aol.com> writes:

> Another question if I may: is this usual in the XML world (to ignore
> additional imports of the same namespace)?

I know that this is how Xerces-C++ works. I am also pretty sure that
Xerces-J works the same way since they have a similar XML Schema
processor architecture. I don't know about other XML Schema
processors but I would imagine most of them use namespaces to identify
grammars (see below). There is an online service that allows you to
test several XML Schema processors. You may want to try that:

http://www.mel.nist.gov/msid/XML_testbed/validation.html


> I was reading the spec (http://www.w3.org/TR/xmlschema-1/#composition-schemaImport
> see Note an the end of section: 4.2.3 References to schema components across
> namespaces?), and while the spec allows this, it mentions that this
> is risky behavior.

The only proper way to support multi-import'ing is to parse every file
and detect duplicate declarations/definitions. There is no way to use
schemaLocation to figure out if it is the same resource because of
aliasing, etc. So while the spec may say it is risky, processor
implementers may say that it's the only reasonable way to do it
(performance and complexity-wise).


> I'm asking because the entity that we receive these schema from declare
> that they are compliant to the above spec? ( Apparently they are ), but
> if it is an industry practice to ignore the later imports, I'll have
> some leverage to get them to change the structure.

I think, especially in case of XML Schema, it is not very smart to use
the spec as an excuse to do things in ways that don't work across widely-
used schema processors.

Also, for what it's worth, we have a large repository of schemas, both
public and proprietary. I haven't seen a single schema that had the
same property as yours. This makes me think that the industry generally
avoids having such a structure in their schemas for some reason.

Boris


From mhoffm1060 at aol.com  Tue Nov 27 13:14:07 2007
From: mhoffm1060 at aol.com (mhoffm1060@aol.com)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] Attributes not found from imported schemas
In-Reply-To: <20071127100442.GC23335@karelia>
References: <8C9FE67316F8D37-2520-425B@webmail-mf16.sysops.aol.com>
	<20071126205036.GC21025@karelia>
	<8C9FE97F1972A57-2574-46C@webmail-mf16.sysops.aol.com>
	<20071127100442.GC23335@karelia>
Message-ID: <8C9FF386F404436-F44-1A5E@FWM-D06.sysops.aol.com>



Hi Boris,
 
> Hi Mark,

> mhoffm1060@aol.com <mhoffm1060@aol.com> writes:

> > Another question if I may: is this usual in the XML world (to ignore
> > additional imports of the same namespace)?

> I know that this is how Xerces-C++ works. I am also pretty sure that
> Xerces-J works the same way since they have a similar XML Schema
> processor architecture. I don't know about other XML Schema
> processors but I would imagine most of them use namespaces to identify
> grammars (see below). There is an online service that allows you to
> test several XML Schema processors. You may want to try that:

> http://www.mel.nist.gov/msid/XML_testbed/validation.html


Cool.  Thanks for the link.

> > I was reading the spec (http://www.w3.org/TR/xmlschema-1/#composition-schemaImport
> > see Note an the end of section: 4.2.3 References to schema components across
> > namespaces?), and while the spec allows this, it mentions that this
> > is risky behavior.

> The only proper way to support multi-import'ing is to parse every file
> and detect duplicate declarations/definitions. There is no way to use
> schemaLocation to figure out if it is the same resource because of
> aliasing, etc. So while the spec may say it is risky, processor
> implementers may say that it's the only reasonable way to do it
> (performance and complexity-wise).

That's what I was thinking.

> > I'm asking because the entity that we receive these schema from declare
> > that they are compliant to the above spec? ( Apparently they are ), but
> > if it is an industry practice to ignore the later imports, I'll have
> > some leverage to get them to change the structure.

> I think, especially in case of XML Schema, it is not very smart to use
> the spec as an excuse to do things in ways that don't work across widely-
> used schema processors.

 


Hopefully they will see it that way.

> Also, for what it's worth, we have a large repository of schemas, both
> public and proprietary. I haven't seen a single schema that had the
> same property as yours. This makes me think that the industry generally
> avoids having such a structure in their schemas for some reason.
 
Good information.  Thanks.

> Boris
 
Again thanks for your response, it is very helpful.
 
Mark



________________________________________________________________________
More new features than ever.  Check out the new AOL Mail ! - http://o.aolcdn.com/cdn.webmail.aol.com/mailtour/aol/en-us/text.htm?ncid=aolcmp00050000000003

From Andrew.McDonald at vgt.net  Tue Nov 27 14:46:43 2007
From: Andrew.McDonald at vgt.net (Andrew McDonald)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] cout problem with hexBinary
Message-ID: <EE905BC23C43984FBF9DF6CAEEFB942F034F8FBC@vgtmail001.vgt.net>


I could use some help with hexBinary.


Schema file snippet:
        <xsd:element name="comPortAddress" type="xsd:hexBinary"   minOccurs="0" />

Corresponding XML config file:
	 <comPortAddress>03F8</comPortAddress>

Source code that breaks:
        std::cout << "comPortAddress: " <<  sas->comPortAddress() << "\n" ;


Compiler output:

Compiling...
codesynthesis.cpp
c:\Program Files\CodeSynthesis XSD 3.0\include\xsd\cxx\tree\containers.txx(276) : error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'const saswrapper_t::comPortAddress_type' (or there is no acceptable conversion)
        c:\dev\misc\test\xml\codesynthesis\codesynthesis.cpp(75) : see reference to function template instantiation 'std::basic_ostream<_Elem,_Traits> &xsd::cxx::tree::operator <<<char,saswrapper_t::comPortAddress_type,false>(std::basic_ostream<_Elem,_Traits> &,const xsd::cxx::tree::optional<X> &)' being compiled
        with
        [
            _Elem=char,
            _Traits=std::char_traits<char>,
            X=saswrapper_t::comPortAddress_type
        ]


"Zufall ist nur der Ausdruck unserer Unf?higkeit, den Dingen auf Grund zu kommen" - Albert Einstein
?




------------------------------------- Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the 
individual or entity to whom they are addressed. If you have received this email in error please notify 
postmaster@vgt.net. This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not disseminate, distribute or 
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by 
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified 
that disclosing, copying, distributing or taking any action in reliance on the contents of this information 
is strictly prohibited. 



From boris at codesynthesis.com  Tue Nov 27 14:56:47 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] cout problem with hexBinary
In-Reply-To: <EE905BC23C43984FBF9DF6CAEEFB942F034F8FBC@vgtmail001.vgt.net>
References: <EE905BC23C43984FBF9DF6CAEEFB942F034F8FBC@vgtmail001.vgt.net>
Message-ID: <20071127195647.GB25958@karelia>

Hi Andrew,

Andrew McDonald <Andrew.McDonald@vgt.net> writes:

> Schema file snippet:
>         <xsd:element name="comPortAddress" type="xsd:hexBinary" minOccurs="0" />
>
> Corresponding XML config file:
> 	 <comPortAddress>03F8</comPortAddress>
>
> Source code that breaks:
>         std::cout << "comPortAddress: " <<  sas->comPortAddress() << "\n" ;

Have you compiled your schemas with the --generate-ostream options?
This option triggers generation/inclusion of std::ostream insertion
operators (operator<<) which appear to be missing in your case.

Also note that comPortAddress is optional (minOccurs="0") so you may
want to check whether it is present first:

if (sas->comPortAddress().present ())
{
  std::cout << "comPortAddress: " <<  sas->comPortAddress().get () << "\n" ;
}

or, same as above but using the pointer notation:

if (sas->comPortAddress())
{
  std::cout << "comPortAddress: " <<  *sas->comPortAddress() << "\n" ;
}

For more information on how to access optional (and other kinds of)
elements and attributes, see Chapter 4, "Working with Object Models"
in the C++/Tree Mapping Getting Started Guide:

http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/#4

Boris


From jnw at xs4all.nl  Tue Nov 27 15:08:56 2007
From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco])
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] Accessing the xml:base attribute using cxx-parser.
Message-ID: <15364.194.109.230.85.1196194136.squirrel@webmail.xs4all.nl>

Greetings.

As a companion to my webpage about accessing the xml:base attribute using
cxx-tree [1] I have created a new page about doing the same with
cxx-parser.

http://www.xs4all.nl/~jnw/codesynthesis/xmlnamespace/parser.html

Having completed this, I wonder why the C++/Parser Mapping Getting Started
Guide [2] does not open with a reference to cxx-parser options
--generate-print-impl and --generate-test-driver. I was very pleased when
I found out about them before having written any code. :)

I also wonder if I have missed any magic to do with cxx-parser what the
customization of anyType achieves for cxx-tree.

Regards,

Jeroen.

[1] http://www.xs4all.nl/~jnw/codesynthesis/xmlnamespace/index.html

[2] http://www.codesynthesis.com/projects/xsd/documentation/cxx/parser/guide/


From boris at codesynthesis.com  Wed Nov 28 02:30:40 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] Accessing the xml:base attribute using cxx-parser.
In-Reply-To: <15364.194.109.230.85.1196194136.squirrel@webmail.xs4all.nl>
References: <15364.194.109.230.85.1196194136.squirrel@webmail.xs4all.nl>
Message-ID: <20071128073040.GC27637@karelia>

Hi Jeroen,

Jeroen N. Witmond [Bahco] <jnw@xs4all.nl> writes:

> As a companion to my webpage about accessing the xml:base attribute using
> cxx-tree [1] I have created a new page about doing the same with
> cxx-parser.
>
> http://www.xs4all.nl/~jnw/codesynthesis/xmlnamespace/parser.html

Nice. I've added this link to the C++/Parser page in the wiki:

http://wiki.codesynthesis.com/Parser


> Having completed this, I wonder why the C++/Parser Mapping Getting Started
> Guide [2] does not open with a reference to cxx-parser options
> --generate-print-impl and --generate-test-driver. I was very pleased when
> I found out about them before having written any code. :)

We were afraid some people may think of this as a blatant self-
promotion ;-). Seriously though, these options are discussed in
Section 2.3 of the "Hello World" chapter, as soon as the reader
has an idea what the C++/Parser mapping is about.


> I also wonder if I have missed any magic to do with cxx-parser what the
> customization of anyType achieves for cxx-tree.

There are a couple of ways to save typing, especially if you have a
lot of parsers that need to handle xml:* attributes. Both ways use
C++ mixin idiom to add xml:base attribute parsing to other parsers.

The first example[1] provides implementation of the _any_attribute()
function as a mixin. It is based on and is very similar to your
parser-wildcard example.

The second example[2] uses the low-level _attribute() callback to
intercept all attributes. It then handles xml:base itself and
delegates parsing of other attributes to the original implementation.
One advantage of this approach is that it will support xml:base
even if the schema does not allow it (provided you have disabled
validation in the underlying XML parser or is using validation in
the generated code).

[1] http://codesynthesis.com/~boris/tmp/lax-pimpl-any-mixin.hpp
[2] http://codesynthesis.com/~boris/tmp/lax-pimpl-intercept-mixin.hpp

Boris


From jnw at xs4all.nl  Wed Nov 28 12:13:28 2007
From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco])
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] Accessing the xml:base attribute using cxx-parser.
Message-ID: <10190.194.109.230.85.1196270008.squirrel@webmail.xs4all.nl>

Hi Boris,

Boris Kolpackov <boris@codesynthesis.com> writes:
> Jeroen N. Witmond [Bahco] <jnw@xs4all.nl> writes:
>
>> As a companion to my webpage about accessing the xml:base attribute
>> using
>> cxx-tree [1] I have created a new page about doing the same with
>> cxx-parser.
>>
>> http://www.xs4all.nl/~jnw/codesynthesis/xmlnamespace/parser.html
>
> Nice. I've added this link to the C++/Parser page in the wiki:
>
> http://wiki.codesynthesis.com/Parser

Thanks.

>> Having completed this, I wonder why the C++/Parser Mapping Getting
>> Started
>> Guide [2] does not open with a reference to cxx-parser options
>> --generate-print-impl and --generate-test-driver. I was very pleased
>> when
>> I found out about them before having written any code. :)
>
> We were afraid some people may think of this as a blatant self-
> promotion ;-). Seriously though, these options are discussed in
> Section 2.3 of the "Hello World" chapter, as soon as the reader
> has an idea what the C++/Parser mapping is about.

Oops, my bad. :) I'm not a sequential reader. The 'generated' example was
an eye-opener for me.

>> I also wonder if I have missed any magic to do with cxx-parser what the
>> customization of anyType achieves for cxx-tree.
>
> There are a couple of ways to save typing, especially if you have a
> lot of parsers that need to handle xml:* attributes. Both ways use
> C++ mixin idiom to add xml:base attribute parsing to other parsers.
>
> The first example[1] provides implementation of the _any_attribute()
> function as a mixin. It is based on and is very similar to your
> parser-wildcard example.
>
> The second example[2] uses the low-level _attribute() callback to
> intercept all attributes. It then handles xml:base itself and
> delegates parsing of other attributes to the original implementation.
> One advantage of this approach is that it will support xml:base
> even if the schema does not allow it (provided you have disabled
> validation in the underlying XML parser or is using validation in
> the generated code).
>
> [1] http://codesynthesis.com/~boris/tmp/lax-pimpl-any-mixin.hpp
> [2] http://codesynthesis.com/~boris/tmp/lax-pimpl-intercept-mixin.hpp

Wow! I've downloaded and read them, and they are just the magic I need. I
had seen the 'multiroot' example, but I the penny did not drop. :) Do I
have your permisssion to add your examples and your descriptions to my
webpage?

Regards,

Jeroen.



From a.colombo at kingston.ac.uk  Thu Nov 29 07:40:35 2007
From: a.colombo at kingston.ac.uk (Alberto Colombo)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] segfault on auto_ptr release
Message-ID: <1196340035.20057.23.camel@caretaker1>

Hello,

I've been successfully using xsd for quite some time, but now I've
stumbled upon a problem I cannot solve.

I am using ViPer (http://viper-toolkit.sourceforge.net/) and its xml
files (schemas and example attached). The original schema file,
downloadable from viper's website, had some problems (including an UPA
violation and some inconsistencies with the actual XML files), so I made
some small changes and now it compiles and the sample file validates.

The problem is that, when I run the very simple program (Assess.cpp), it
crashes when the auto_ptr destructor is invoked. This happens both on
windows and linux (either with segmentation fault or illegal
instruction, randomly), using xsd 3.0.0.

On more complex use cases, the xsd seems to be generating a corrupted
data structure (e.g., where empty sequences have .begin() != .end()).

Can anyone confirm the error, and point me to a solution?

Thank you very much.
Best Regards,
Alberto Colombo

-- 
Alberto Colombo, MSc

PhD student at Digital Imaging Research Centre
Kingston University, London

e-mail: a.colombo@kingston.ac.uk
  cell: +44 77267 11980
  http://dircweb.king.ac.uk/Ris/queries/pages/home_page.asp?AuthorID=925


This email has been scanned for all viruses by the MessageLabs Email
Security System.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: viper.xsd
Type: application/xml
Size: 6707 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071129/b7823f5c/viper.xml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: viperdata.xsd
Type: application/xml
Size: 5828 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071129/b7823f5c/viperdata.xml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sample-lamp.xgtf
Type: application/xml
Size: 28262 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071129/b7823f5c/sample-lamp.xml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Assess.cpp
Type: text/x-c++src
Size: 422 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071129/b7823f5c/Assess.cpp
From boris at codesynthesis.com  Thu Nov 29 10:20:40 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] segfault on auto_ptr release
In-Reply-To: <1196340035.20057.23.camel@caretaker1>
References: <1196340035.20057.23.camel@caretaker1>
Message-ID: <20071129152040.GF16053@karelia>

Hi Alberto,

Alberto Colombo <a.colombo@kingston.ac.uk> writes:

> The problem is that, when I run the very simple program (Assess.cpp), it
> crashes when the auto_ptr destructor is invoked. This happens both on
> windows and linux (either with segmentation fault or illegal
> instruction, randomly), using xsd 3.0.0.

I tried your test case but got the following validation errors instead
of a segfault:

sample-lamp.xgtf:24:50 error: Unknown element 'data:polygon-type'
sample-lamp.xgtf:24:50 error: Attribute 'open' is not declared for element 'data:polygon-type'
sample-lamp.xgtf:49:66 error: Duplicate unique value declared for identity constraint of element 'sourcefile'.
sample-lamp.xgtf:232:51 error: Unknown element 'data:polygon'
sample-lamp.xgtf:232:51 error: Attribute 'framespan' is not declared for element 'data:polygon'
sample-lamp.xgtf:240:29 error: Element 'data:polygon' is not valid for content model: '(null,)'
sample-lamp.xgtf:476:57 error: Duplicate unique value declared for identity constraint of element 'sourcefile'.
sample-lamp.xgtf:485:57 error: Duplicate unique value declared for identity constraint of element 'sourcefile'.

I could find neither data:polygon-type nor data:polygon elements in the
schemas you provided so clearly your sample XML is not valid per your
schemas.

Can you send a valid XML document that I can use to reproduce this
problem? But before you do, can you confirm that you've compiled
all your schemas with the --generate-polymorphic as suggested by
the warning? If that's not the case, then please try to add this
option and see if problem goes away.

Thanks,
Boris


From a.colombo at kingston.ac.uk  Thu Nov 29 13:07:36 2007
From: a.colombo at kingston.ac.uk (Alberto Colombo)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] segfault on auto_ptr release
In-Reply-To: <20071129152040.GF16053@karelia>
References: <1196340035.20057.23.camel@caretaker1>
	<20071129152040.GF16053@karelia>
Message-ID: <1196359656.20057.37.camel@caretaker1>

Hello Boris,

> > The problem is that, when I run the very simple program (Assess.cpp), it
> > crashes when the auto_ptr destructor is invoked. This happens both on
> > windows and linux (either with segmentation fault or illegal
> > instruction, randomly), using xsd 3.0.0.

> Can you send a valid XML document that I can use to reproduce this
> problem? But before you do, can you confirm that you've compiled
> all your schemas with the --generate-polymorphic as suggested by
> the warning? If that's not the case, then please try to add this
> option and see if problem goes away.

sorry! I had the wrong file attached. This one should validate.

I compiled the schemas with the following options:

--generate-polymorphic 
--generate-serialization
--generate-ostream 
--generate-comparison
--generate-wildcard
--root-element-all 

Thanks again
alberto

-- 
Alberto Colombo, MSc

PhD student at Digital Imaging Research Centre
Kingston University, London

e-mail: a.colombo@kingston.ac.uk
  cell: +44 77267 11980
  http://dircweb.king.ac.uk/Ris/queries/pages/home_page.asp?AuthorID=925


This email has been scanned for all viruses by the MessageLabs Email
Security System.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sample-lamp-2.xgtf
Type: application/xml
Size: 27894 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071129/7be4fa3a/sample-lamp-2.xml
From boris at codesynthesis.com  Fri Nov 30 01:36:07 2007
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] segfault on auto_ptr release
In-Reply-To: <1196359656.20057.37.camel@caretaker1>
References: <1196340035.20057.23.camel@caretaker1>
	<20071129152040.GF16053@karelia>
	<1196359656.20057.37.camel@caretaker1>
Message-ID: <20071130063607.GA30887@karelia>

Hi Alberto,

Alberto Colombo <a.colombo@kingston.ac.uk> writes:

> I compiled the schemas with the following options:
>
> [...]
>
> --generate-wildcard

Ok, that explains it. When you use the --generate-wildcard option,
the mapping uses Xerces-C++ DOM fragments to represent content
matched by wildcards. As a result, you need to have the Xerces-C++
runtime initialized for the lifetime of your object model.

For more information, see Section 2.12, "Mapping for any and anyAttribute"
in the C++/Tree Mapping User Manual:

http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.12

As well as the wildcard example in examples/cxx/tree/. I am also attaching
the modified Assess.cpp file for your reference.

Boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Assess.cpp
Type: text/x-c++src
Size: 565 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20071130/aa417e03/Assess.cpp
From a.colombo at kingston.ac.uk  Fri Nov 30 05:41:17 2007
From: a.colombo at kingston.ac.uk (Alberto Colombo)
Date: Sun Oct 11 15:34:00 2009
Subject: [xsd-users] segfault on auto_ptr release
In-Reply-To: <20071130063607.GA30887@karelia>
References: <1196340035.20057.23.camel@caretaker1>
	<20071129152040.GF16053@karelia> <1196359656.20057.37.camel@caretaker1>
	<20071130063607.GA30887@karelia>
Message-ID: <1196419277.24181.21.camel@caretaker1>

Hi Boris,

that solves the problem, thank you very much! 

Regards
Alberto

PS: I had RTFM'd before posting, but the manual is too large to fit in
my brain as a whole!

On Fri, 2007-11-30 at 08:36 +0200, Boris Kolpackov wrote:
> Hi Alberto,
> 
> Alberto Colombo <a.colombo@kingston.ac.uk> writes:
> 
> > I compiled the schemas with the following options:
> >
> > [...]
> >
> > --generate-wildcard
> 
> Ok, that explains it. When you use the --generate-wildcard option,
> the mapping uses Xerces-C++ DOM fragments to represent content
> matched by wildcards. As a result, you need to have the Xerces-C++
> runtime initialized for the lifetime of your object model.
> 
> For more information, see Section 2.12, "Mapping for any and anyAttribute"
> in the C++/Tree Mapping User Manual:
> 
> http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.12
> 
> As well as the wildcard example in examples/cxx/tree/. I am also attaching
> the modified Assess.cpp file for your reference.
> 
> Boris
> 
> 
> This email has been scanned for all viruses by the MessageLabs Email
> Security System.
-- 
Alberto Colombo, MSc

PhD student at Digital Imaging Research Centre
Kingston University, London

e-mail: a.colombo@kingston.ac.uk
  cell: +44 77267 11980
  http://dircweb.king.ac.uk/Ris/queries/pages/home_page.asp?AuthorID=925

This email has been scanned for all viruses by the MessageLabs Email
Security System.