From boris at codesynthesis.com  Tue Aug  1 05:53:36 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] Re: Building examples on Linux
In-Reply-To: <44CE76A7.3070909@saic-asd.com>
References: <44CE16F6.1000104@saic-asd.com> <20060731153208.GA8747@karelia>
	<44CE2B8F.4020202@saic-asd.com> <20060731191827.GA9224@karelia>
	<44CE6016.6000001@saic-asd.com> <20060731201900.GA9374@karelia>
	<44CE76A7.3070909@saic-asd.com>
Message-ID: <20060801095336.GB10956@karelia>

Hi Jason,

Jason Wang <jwang@saic-asd.com> writes:

> one more question.  I have a set of xml schema files and some of them
> are common xml files used by a few others.  Is there a issue with xsd?
> or will duplicated c++ classes being generated or name collisions?

Not at all. XSD supports separate compilation of schemas. You are most
likely using XML Schema include or import facility to connect your
schemas. XSD maps them to #include directives. You will simply need
to compile each schema separately and compile and link the resulting
C++ source files into your application.


> any document on that?

Sure. This is described in detail in the "Mapping for import and include"
section[1] of the "C++/Tree Mapping User Manual"[2].


[1] http://codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.3
[2] http://codesynthesis.com/projects/xsd/documentation/cxx/tree/manual


hth,
-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/20060801/643534ba/attachment.pgp
From Bastien.Cojan at cadcorp.com  Tue Aug  1 10:55:31 2006
From: Bastien.Cojan at cadcorp.com (Bastien Cojan)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] xsd
Message-ID: <AA31868BC8CE1B4DB132141A6556A20A0A495F@dev010_ex.Dev.cadcorp.net>

Hi, 
I am testing the c++ parser generation on different schemas which
contain <restriction> and <extension> tags

When I try to generate a parser from the following schema, I get this
error : 

error C2991: redefinition of template parameter '_xsd_test_'

In the generated code

<xsd:schema targetNamespace="http://www.test.co.uk/test"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns="http://www.test.co.uk/test" elementFormDefault="qualified"
attributeFormDefault="unqualified">
    <xsd:complexType name="test_type">
        <xsd:sequence>
            <xsd:element name="test" type="xsd:string" />
        </xsd:sequence>
    </xsd:complexType>
    <xsd:complexType name="hello_type">
        <xsd:complexContent>
            <xsd:extension base="test_type">
                <xsd:sequence>
                    <xsd:element name="greeting" type="xsd:string" />
                    <xsd:element name="name" type="xsd:string"
maxOccurs="unbounded" />
                    <xsd:element name="test" type="xsd:string" />
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
    <xsd:element name="hello" type="hello_type" />
</xsd:schema>

It seems like it does not detect the test element inside the extension. 


Regards,
Bastien ,
Senior developer,
Cadcorp


From boris at codesynthesis.com  Tue Aug  1 14:51:31 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] xsd
In-Reply-To: <AA31868BC8CE1B4DB132141A6556A20A0A495F@dev010_ex.Dev.cadcorp.net>
References: <AA31868BC8CE1B4DB132141A6556A20A0A495F@dev010_ex.Dev.cadcorp.net>
Message-ID: <20060801185131.GB12410@karelia>

Hi Bastien,

Bastien Cojan <Bastien.Cojan@cadcorp.com> writes:

> When I try to generate a parser from the following schema, I get this
> error :
>
> error C2991: redefinition of template parameter '_xsd_test_'
>
> In the generated code
>
> ...
>
>     <xsd:complexType name="test_type">
>         <xsd:sequence>
>             <xsd:element name="test" type="xsd:string" />
>         </xsd:sequence>
>     </xsd:complexType>
>     <xsd:complexType name="hello_type">
>         <xsd:complexContent>
>             <xsd:extension base="test_type">
>                 <xsd:sequence>
>                     <xsd:element name="greeting" type="xsd:string" />
>                     <xsd:element name="name" type="xsd:string" maxOccurs="unbounded" />
>                     <xsd:element name="test" type="xsd:string" />
>                 </xsd:sequence>
>             </xsd:extension>
>         </xsd:complexContent>
>     </xsd:complexType>
>
> ...
>
> It seems like it does not detect the test element inside the extension.

This is a known limitation of the C++/Parser mapping. The 'test'
element in the extension should be detected as the same as in the
base type and should either be escaped or the base's hook should
be reused (we are not at the moment sure which way is better).
We do such detection across the particle hierarchy in the same
type but not across the type inheritance hierarchy.


We could probably fix this if you are interested in using the
C++/Parser mapping in your application and would like to help
figure our the details.


hth,
-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/20060801/8cc3b7a4/attachment.pgp
From boris at codesynthesis.com  Wed Aug  2 09:01:21 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] Build instructions for UNIX
Message-ID: <20060802130121.GA18193@karelia>

Hi,

A step-by-step guide on how to build XSD from source on UNIX-like
operating systems (GNU/Linux, Mac OS X, Solaris, HP-UX, etc.) is
now available:

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

There is also a similar guide for Windows:

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


have fun,
-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/20060802/97c5e4d8/attachment.pgp
From jjerryda at hotmail.com  Thu Aug  3 22:51:40 2006
From: jjerryda at hotmail.com (chenqi)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] How to express my own Object type in schema file??
Message-ID: <BAY121-W13ECC9D10E4D4D58D3E1C6D6500@phx.gbl>

Hi,all
 
I'm now writing a wsdl schema file ,i met a problem: i don't know how to express my own Object type in the 
schema file. For example:
 
I create a java Object: "TestObject",then i have a method in my service code ,this method uses one parameter
of "TestObject" type ,
 
In the schema file ,how to express the "TypeObject" type??
 
<xsd:element name="getMemberShipContentRules" type="TestObject"/><xsd:element name="getMemberShipContentRulesResponse" type="xsd:string"/>
 
Thanks ,:)
 
chenqi
_________________________________________________________________
Windows Live Safety Center ??????????????????
http://safety.live.com/site/ZH-CN/default.htm
From boris at codesynthesis.com  Fri Aug  4 04:20:02 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] How to express my own Object type in schema file??
In-Reply-To: <BAY121-W13ECC9D10E4D4D58D3E1C6D6500@phx.gbl>
References: <BAY121-W13ECC9D10E4D4D58D3E1C6D6500@phx.gbl>
Message-ID: <20060804082002.GA22848@karelia>

Hi,

This mailing list is for technical discussions about CodeSynthesis XSD -
XML Schema to C++ data binding compiler, as stated on the mailing list
info page[1].

To find an answer to your question I suggest you read a tutorial on
XML Schema, for example XML Schema Part 0: Primer[2].


[1] http://codesynthesis.com/mailman/listinfo/xsd-users
[2] http://www.w3.org/TR/xmlschema-0/


hth,
-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/20060804/afa53b2f/attachment.pgp
From Antonio.Moschini at siemens.com  Fri Aug  4 07:47:07 2006
From: Antonio.Moschini at siemens.com (Moschini Antonio)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] Compile problem with xsd schema
Message-ID: <2807C9DA6DEFC04595B09600D99C92E222C482@MILVL0PA.icn.siemens.it>

Hi all,
I need help on this error generated by Visual Studio .NET2005 compiling
a schema of 12581 lines.
"d:\..\schema.cxx(271153) : fatal error C1061: compiler limit : blocks
nested too deeply".
 
The command I use for xsd is 
"xsd cxx-tree --generate-ostream --generate-insertion
--generate-extraction --namespace-map http://rules.com=schema
--morph-anonymous --root-element-first schema.xsd"
 
Thanks a lot
Antonio Moschini


From boris at codesynthesis.com  Fri Aug  4 07:55:52 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] Compile problem with xsd schema
In-Reply-To: <2807C9DA6DEFC04595B09600D99C92E222C482@MILVL0PA.icn.siemens.it>
References: <2807C9DA6DEFC04595B09600D99C92E222C482@MILVL0PA.icn.siemens.it>
Message-ID: <20060804115552.GA23157@karelia>

Hi Antonio,

Moschini Antonio <Antonio.Moschini@siemens.com> writes:

> I need help on this error generated by Visual Studio .NET2005 compiling
> a schema of 12581 lines.
> "d:\..\schema.cxx(271153) : fatal error C1061: compiler limit : blocks
> nested too deeply".

We will need to see the code fragment (preferably all the way up to the
namespace scope) around this line. Providing corresponding schema fragment
might also help.


hth,
-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/20060804/e47d8613/attachment.pgp
From Remsy.Schmilinsky at ccra-adrc.gc.ca  Fri Aug  4 08:00:22 2006
From: Remsy.Schmilinsky at ccra-adrc.gc.ca (Schmilinsky, Remsy)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] build xsd on cygwin fail
Message-ID: <D46B9A114A1DAD48B88719C1C1043D80039FE676@sh24x696.rc.gc.ca>

Hi Boris. I am trying to build xsd by following the steps outlined in the windows installation instructions for cygwin http://www.codesynthesis.com/projects/xsd/extras/build-windows.xhtml However it fails when I reach libxsd-frontend, everything before that goes well. Here is the output (I've tried twice and always the same error, using windows 2000 / cygwin). It looks like there something wrong with the libcult, but maybe you can help me:

m4 /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/fundamental.cxx.m4
m4 /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/fundamental.hxx.m4
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/any.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/attribute.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/attribute-group.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/complex.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/compositors.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/element.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/element-group.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/elements.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/enumeration.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/fundamental.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/list.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/namespace.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/particle.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/schema.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/semantic-graph/union.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/traversal/attribute.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/traversal/attribute-group.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/traversal/complex.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/traversal/compositors.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/traversal/element.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/traversal/element-group.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/traversal/elements.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/traversal/enumeration.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/traversal/fundamental.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/traversal/list.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/traversal/namespace.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/traversal/schema.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/traversal/union.cxx
c++ /usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx
/usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx: In member function `virtual Cult::Types::Fundamental::Void XSDFrontend
::<unnamed>::Resolver::traverse(XSDFrontend::SemanticGraph::Complex&)':
/usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx:500: error: invalid initialization of reference of type 'XSDFrontend::<
unnamed>::AttributeGroupRefs&' from expression of type 'const Cult::Containers::Vector<XSDFrontend::<unnamed>::AttributeGroupR
ef>'
/usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx:521: error: invalid initialization of reference of type 'XSDFrontend::<
unnamed>::ElementGroupRef&' from expression of type 'const XSDFrontend::<unnamed>::ElementGroupRef'
/usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx: In member function `virtual Cult::Types::Fundamental::Void XSDFrontend
::<unnamed>::Resolver::traverse(XSDFrontend::SemanticGraph::AttributeGroup&)':
/usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx:592: error: invalid initialization of reference of type 'XSDFrontend::<
unnamed>::AttributeGroupRefs&' from expression of type 'const Cult::Containers::Vector<XSDFrontend::<unnamed>::AttributeGroupR
ef>'
/usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx: In member function `virtual Cult::Types::Fundamental::Void XSDFrontend
::<unnamed>::Resolver::traverse(XSDFrontend::SemanticGraph::Compositor&)':
/usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx:620: error: invalid initialization of reference of type 'XSDFrontend::<
unnamed>::ElementGroupRefs&' from expression of type 'const Cult::Containers::Vector<XSDFrontend::<unnamed>::ElementGroupRef>'

/usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx: In member function `Cult::Types::Fundamental::Void XSDFrontend::Parser
::Impl::element_group(const XSDFrontend::XML::Element&)':
/usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx:1788: error: passing `const XSDFrontend::<unnamed>::ElementGroupRefs' a
s `this' argument of `void stlp_std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = XSDFrontend::<unnamed>::ElementGro
upRef, _Alloc = stlp_std::allocator<XSDFrontend::<unnamed>::ElementGroupRef>]' discards qualifiers
/usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx: In member function `Cult::Types::Fundamental::Void XSDFrontend::Parser
::Impl::attribute_group(const XSDFrontend::XML::Element&)':
/usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx:2978: error: passing `const XSDFrontend::<unnamed>::AttributeGroupRefs'
 as `this' argument of `void stlp_std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = XSDFrontend::<unnamed>::Attribut
eGroupRef, _Alloc = stlp_std::allocator<XSDFrontend::<unnamed>::AttributeGroupRef>]' discards qualifiers
make: *** [/usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.o] Error 1

From boris at codesynthesis.com  Fri Aug  4 08:11:20 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] build xsd on cygwin fail
In-Reply-To: <D46B9A114A1DAD48B88719C1C1043D80039FE676@sh24x696.rc.gc.ca>
References: <D46B9A114A1DAD48B88719C1C1043D80039FE676@sh24x696.rc.gc.ca>
Message-ID: <20060804121120.GB23157@karelia>

Hi Remsy,

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> I am trying to build xsd by following the steps outlined in the windows
> installation instructions for cygwin
> http://www.codesynthesis.com/projects/xsd/extras/build-windows.xhtml
> However it fails when I reach libxsd-frontend, everything before that
> goes well. Here is the output (I've tried twice and always the same
> error, using windows 2000 / cygwin). It looks like there something
> wrong with the libcult, but maybe you can help me:
>
> /usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx: In member function `virtual Cult::Types::Fundamental::Void XSDFrontend
> ::<unnamed>::Resolver::traverse(XSDFrontend::SemanticGraph::Complex&)':
> /usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx:500: error: invalid initialization of reference of type 'XSDFrontend::<
> unnamed>::AttributeGroupRefs&' from expression of type 'const Cult::Containers::Vector<XSDFrontend::<unnamed>::AttributeGroupR
> ef>'

I think you have a version mismatch between libcult and libxsd-frontend.
I suggest you try to upgrade to the latest distributions of all the
components (build, libcult, libfrontend-elements, libbackend-elements,
libxsd-frontend, and xsd). If you really need to use 1.6.0 then I suggest
you use exactly the versions of the components that are specified in the
INSTALL files of libxsd-frontend-1.6.0 and xsd-2.1.0.


hth,
-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/20060804/317f9686/attachment.pgp
From Remsy.Schmilinsky at ccra-adrc.gc.ca  Fri Aug  4 09:37:17 2006
From: Remsy.Schmilinsky at ccra-adrc.gc.ca (Schmilinsky, Remsy)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] RE: build xsd on cygwin fail
Message-ID: <D46B9A114A1DAD48B88719C1C1043D80039FE677@sh24x696.rc.gc.ca>

Hi Boris, it worked using the latest versions of build, libcult,
libfrontend-elements, libbackend-elements,
libxsd-frontend, and xsd. Can you add this note in the installation
instructions for the newcomers?

thanks,

Remsy

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com]
Sent: August 4, 2006 8:11 AM
To: Schmilinsky, Remsy
Cc: xsd-users@codesynthesis.com
Subject: Re: [xsd-users] build xsd on cygwin fail


Hi Remsy,

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> I am trying to build xsd by following the steps outlined in the
windows
> installation instructions for cygwin
> http://www.codesynthesis.com/projects/xsd/extras/build-windows.xhtml
> However it fails when I reach libxsd-frontend, everything before that
> goes well. Here is the output (I've tried twice and always the same
> error, using windows 2000 / cygwin). It looks like there something
> wrong with the libcult, but maybe you can help me:
>
> /usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx: In member
function `virtual Cult::Types::Fundamental::Void XSDFrontend
>
::<unnamed>::Resolver::traverse(XSDFrontend::SemanticGraph::Complex&)':
> /usr/src/libxsd-frontend-1.6.0/xsd-frontend/parser.cxx:500: error:
invalid initialization of reference of type 'XSDFrontend::<
> unnamed>::AttributeGroupRefs&' from expression of type 'const
Cult::Containers::Vector<XSDFrontend::<unnamed>::AttributeGroupR
> ef>'

I think you have a version mismatch between libcult and libxsd-frontend.
I suggest you try to upgrade to the latest distributions of all the
components (build, libcult, libfrontend-elements, libbackend-elements,
libxsd-frontend, and xsd). If you really need to use 1.6.0 then I
suggest
you use exactly the versions of the components that are specified in the
INSTALL files of libxsd-frontend-1.6.0 and xsd-2.1.0.


hth,
-boris


From Remsy.Schmilinsky at ccra-adrc.gc.ca  Fri Aug  4 10:02:51 2006
From: Remsy.Schmilinsky at ccra-adrc.gc.ca (Schmilinsky, Remsy)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] cannot compile hello cygwin
Message-ID: <D46B9A114A1DAD48B88719C1C1043D80039FE678@sh24x696.rc.gc.ca>

Hi. After building xsd on cygwin, I try to build the hello example (driver application). This is the result:

When I invoked make, I selected the archive option and the path to xerces folder.

$ make driver
xsd /usr/src/xsd-2.2.0/examples/cxx/parser/hello/hello.xsd
\usr\src\xsd-2.2.0\examples\cxx\parser\hello\hello.xsd: error: '\usr\src\xsd-2.2.0\examples\cxx\parser\hello\hello.xsd': unabl
e to open in read mode
make: *** No rule to make target `driver'.  Stop.

From Remsy.Schmilinsky at ccra-adrc.gc.ca  Fri Aug  4 10:05:07 2006
From: Remsy.Schmilinsky at ccra-adrc.gc.ca (Schmilinsky, Remsy)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] cannot compile hello cygwin
Message-ID: <D46B9A114A1DAD48B88719C1C1043D80039FE679@sh24x696.rc.gc.ca>

Correction, it's not "make driver", it's "make" instead:

$ make
xsd /usr/src/xsd-2.2.0/examples/cxx/parser/hello/hello.xsd
\usr\src\xsd-2.2.0\examples\cxx\parser\hello\hello.xsd: error: '\usr\src\xsd-2.2.0\examples\cxx\parser\hello\hello.xsd': unable to open in read mode

-----Original Message-----
From: xsd-users-bounces@codesynthesis.com
[mailto:xsd-users-bounces@codesynthesis.com]
Sent: August 4, 2006 10:03 AM
To: xsd-users@codesynthesis.com
Subject: [xsd-users] cannot compile hello cygwin


Hi. After building xsd on cygwin, I try to build the hello example (driver application). This is the result:

When I invoked make, I selected the archive option and the path to xerces folder.

$ make driver
xsd /usr/src/xsd-2.2.0/examples/cxx/parser/hello/hello.xsd
\usr\src\xsd-2.2.0\examples\cxx\parser\hello\hello.xsd: error: '\usr\src\xsd-2.2.0\examples\cxx\parser\hello\hello.xsd': unabl
e to open in read mode
make: *** No rule to make target `driver'.  Stop.
_______________________________________________
xsd-users mailing list
xsd-users@codesynthesis.com
http://codesynthesis.com/mailman/listinfo/xsd-users


From jf at magnu.polymtl.ca  Fri Aug  4 11:04:51 2006
From: jf at magnu.polymtl.ca (Jean-Francois Dube)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] Compile problem with xsd schema
In-Reply-To: <20060804115552.GA23157@karelia>
References: <2807C9DA6DEFC04595B09600D99C92E222C482@MILVL0PA.icn.siemens.it>
	<20060804115552.GA23157@karelia>
Message-ID: <44D36213.4040601@magnu.polymtl.ca>


   Hi,
   Someone I know had a similar problem with xsd and Visual Studio.
   It's a limitation of the Microsoft compiler. Your schema is probably
   too "deep", and the generated code has too many levels of nested
   class.
   See [1]http://msdn2.microsoft.com/en-us/library/ft39hh4x.aspx
   "Levels of nested class, structure, or union definitions in a single
   struct-declaration-list ... (16)."
   In his case, I think he had 15 levels of embeded elements in his
   schema.
   I don't know if there is a workaround, otherwise you will need to try
   to flaten your schema (put more elements at global scope), ... or
   change compiler.
   JF
   Boris Kolpackov wrote:

Hi Antonio,

Moschini Antonio [2]<Antonio.Moschini@siemens.com> writes:



I need help on this error generated by Visual Studio .NET2005 compiling
a schema of 12581 lines.
"d:\..\schema.cxx(271153) : fatal error C1061: compiler limit : blocks
nested too deeply".


We will need to see the code fragment (preferably all the way up to the
namespace scope) around this line. Providing corresponding schema fragment
might also help.


hth,
-boris
    _______________________________________________________________________

_______________________________________________
xsd-users mailing list
[3]xsd-users@codesynthesis.com
[4]http://codesynthesis.com/mailman/listinfo/xsd-users

References

   1. http://msdn2.microsoft.com/en-us/library/ft39hh4x.aspx
   2. mailto:Antonio.Moschini@siemens.com
   3. mailto:xsd-users@codesynthesis.com
   4. http://codesynthesis.com/mailman/listinfo/xsd-users

From boris at codesynthesis.com  Fri Aug  4 13:51:22 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] Re: build xsd on cygwin fail
In-Reply-To: <D46B9A114A1DAD48B88719C1C1043D80039FE677@sh24x696.rc.gc.ca>
References: <D46B9A114A1DAD48B88719C1C1043D80039FE677@sh24x696.rc.gc.ca>
Message-ID: <20060804175122.GA24069@karelia>

Hi Remsy,

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> Hi Boris, it worked using the latest versions of build, libcult,
> libfrontend-elements, libbackend-elements,
> libxsd-frontend, and xsd. Can you add this note in the installation
> instructions for the newcomers?

I actually added "download the latest X source release" to the
instructions yesterday. Before it was just "download X". Hopefully
this will help. Thanks for the suggestion!


-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/20060804/b01ef198/attachment.pgp
From boris at codesynthesis.com  Fri Aug  4 14:09:18 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] cannot compile hello cygwin
In-Reply-To: <D46B9A114A1DAD48B88719C1C1043D80039FE679@sh24x696.rc.gc.ca>
References: <D46B9A114A1DAD48B88719C1C1043D80039FE679@sh24x696.rc.gc.ca>
Message-ID: <20060804180918.GB24069@karelia>

Remsy,

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> $ make
> xsd /usr/src/xsd-2.2.0/examples/cxx/parser/hello/hello.xsd
> \usr\src\xsd-2.2.0\examples\cxx\parser\hello\hello.xsd: error: '\usr\src\xsd-2.2.0\examples\cxx\parser\hello\hello.xsd': unable to open in read mode

This is because the xsd binary you've just built is a native Win32
executable and expects Win32 path (as stated at the end of the build
instructions) while the build system uses POSIX paths. This binary
is normally used with projects that use "native" C++ compilers such
as VC++. While you can still use native Win32 applications under
Cygwin, you will either need to use relative paths or translate them
using the cygpath utility.

Another alternative, especially if you are planning to develop
exclusively under Cygwin, is to build xsd as a Cygwin executable.
The build instructions should be pretty similar to the ones for
Mingw except you will need to remove the -mno-cygwin option from
the g++ command line and generally watch for places where things
mention Cygwin or Mingw. If you would like to give this a try,
please let me know how it goes. If you run into any problems
I will try to do a complete build myself (and maybe even package
the result as a pre-compiled binary, if there is interest).

hth,
-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/20060804/561c52b0/attachment.pgp
From boris at codesynthesis.com  Fri Aug  4 14:27:33 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] Compile problem with xsd schema
In-Reply-To: <44D36213.4040601@magnu.polymtl.ca>
References: <2807C9DA6DEFC04595B09600D99C92E222C482@MILVL0PA.icn.siemens.it>
	<20060804115552.GA23157@karelia>
	<44D36213.4040601@magnu.polymtl.ca>
Message-ID: <20060804182733.GA24143@karelia>

Hi Jean-Francois,

Jean-Francois Dube <jf@magnu.polymtl.ca> writes:

>    Someone I know had a similar problem with xsd and Visual Studio.
>
>    It's a limitation of the Microsoft compiler. Your schema is probably too
>    "deep", and the generated code has too many levels of nested class.
>
>    See http://msdn2.microsoft.com/en-us/library/ft39hh4x.aspx
>    "Levels of nested class, structure, or union definitions in a single
>    struct-declaration-list ... (16)."
>
>    In his case, I think he had 15 levels of embeded elements in his schema.
>
>    I don't know if there is a workaround, otherwise you will need to try to
>    flaten your schema (put more elements at global scope), ... or change
>    compiler.

I thought so at the first sight but then I saw that he is using the
--morph-anonymous option which means all type nesting is flattened
automatically. As a result there should not be more than 3 levels
of nesting.

There are also other cases where VC++ has hard-coded limits. One
such case is a long if-else-if-else chain. Apparently, VC++ treats
them as nested scopes and if you have a couple of hundreds of those
it complains. This problem was reported with large XML Schema
enumerations and was since fixed. Also the fact that the error is
in the .cxx file suggests that the problem is not with type nesting.
We will know for sure when we see the code ;-).

Thanks for the hint!

-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/20060804/13f1a327/attachment.pgp
From boris at codesynthesis.com  Fri Aug  4 14:33:11 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] cannot compile hello cygwin
In-Reply-To: <D46B9A114A1DAD48B88719C1C1043D80039FE67D@sh24x696.rc.gc.ca>
References: <D46B9A114A1DAD48B88719C1C1043D80039FE67D@sh24x696.rc.gc.ca>
Message-ID: <20060804183311.GB24143@karelia>

Hi Remsy,

I've CC'ed xsd-users back; someone may find this information useful.

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> I see. can you explain how to fix this with the first approach? that is,
> using relative paths or cygpath. In the future I am concentrating on
> linux, but I need cygwin for the moment.

One way to do this is to grab one of the pre-compiled XSD distributions,
for example one for gnu-linux, and replace the linux xsd binary with the
one you've just built. Then cd to examples and say 'make'.

This will work because the simple makefiles we supply for examples in
the pre-compiled distributions use relative paths to compile schemas.


hth,
-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/20060804/7dd22088/attachment.pgp
From Remsy.Schmilinsky at ccra-adrc.gc.ca  Fri Aug  4 14:50:59 2006
From: Remsy.Schmilinsky at ccra-adrc.gc.ca (Schmilinsky, Remsy)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] cannot compile hello cygwin
Message-ID: <D46B9A114A1DAD48B88719C1C1043D80039FE67E@sh24x696.rc.gc.ca>

Ok, so I had to copy the xerces folder and xsd (the .h files) to
/usr/include, also libxerces-c.a into /usr/lib. At the end, I get the
following errors coming from xerces (linkage errors). thanks for your
patience !

$ make
g++ -I../../../../libxsd -W -Wall -c driver.cxx -o driver.o
g++ -W -Wall  -o driver driver.o -lxerces-c
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XMLString.o):XM
LString.cpp:(.text+0x54e): undefined reference to `_st
ricmp'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XMLString.o):XM
LString.cpp:(.text+0x5a2): undefined reference to `_st
rnicmp'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XMLString.o):XM
LString.cpp:(.text+0xcba): undefined reference to `_st
rnicmp'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XMLString.o):XM
LString.cpp:(.text+0xe19): undefined reference to `__i
mp___pctype'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XMLString.o):XM
LString.cpp:(.text+0xe34): undefined reference to `__i
sctype'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XMLString.o):XM
LString.cpp:(.text+0xe5a): undefined reference to `__i
mp___pctype'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XMLString.o):XM
LString.cpp:(.text+0xe75): undefined reference to `__i
sctype'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XMLString.o):XM
LString.cpp:(.text+0x27b7): undefined reference to `__
errno'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XMLString.o):XM
LString.cpp:(.text+0x282d): undefined reference to `__
errno'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XMLString.o):XM
LString.cpp:(.text+0x2bb3): undefined reference to `__
errno'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XMLString.o):XM
LString.cpp:(.text+0x2cde): undefined reference to `__
errno'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(DefaultPanicHan
dler.o):DefaultPanicHandler.cpp:(.text+0x1e): undefine
d reference to `__imp___iob'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XSValue.o):XSVa
lue.cpp:(.text+0x4b62): undefined reference to `__errn
o'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XSValue.o):XSVa
lue.cpp:(.text+0x4c82): undefined reference to `__errn
o'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XSValue.o):XSVa
lue.cpp:(.text+0x4d34): undefined reference to `__errn
o'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XSValue.o):XSVa
lue.cpp:(.text+0x4e07): undefined reference to `__errn
o'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XMLAbstractDoub
leFloat.o):XMLAbstractDoubleFloat.cpp:(.text+0x11ba):
undefined reference to `__errno'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libxerces-c.a(XMLAbstractDoub
leFloat.o):XMLAbstractDoubleFloat.cpp:(.text+0x12b6):
more undefined references to `__errno' follow
collect2: ld returned 1 exit status
make: *** [driver] Error 1

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com]
Sent: August 4, 2006 2:33 PM
To: Schmilinsky, Remsy
Cc: xsd-users@codesynthesis.com
Subject: Re: [xsd-users] cannot compile hello cygwin


Hi Remsy,

I've CC'ed xsd-users back; someone may find this information useful.

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> I see. can you explain how to fix this with the first approach? that
is,
> using relative paths or cygpath. In the future I am concentrating on
> linux, but I need cygwin for the moment.

One way to do this is to grab one of the pre-compiled XSD distributions,
for example one for gnu-linux, and replace the linux xsd binary with the
one you've just built. Then cd to examples and say 'make'.

This will work because the simple makefiles we supply for examples in
the pre-compiled distributions use relative paths to compile schemas.


hth,
-boris


From boris at codesynthesis.com  Fri Aug  4 14:59:58 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] cannot compile hello cygwin
In-Reply-To: <D46B9A114A1DAD48B88719C1C1043D80039FE67E@sh24x696.rc.gc.ca>
References: <D46B9A114A1DAD48B88719C1C1043D80039FE67E@sh24x696.rc.gc.ca>
Message-ID: <20060804185958.GC24143@karelia>

Hi Remsy,

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> Ok, so I had to copy the xerces folder and xsd (the .h files) to
> /usr/include, also libxerces-c.a into /usr/lib. At the end, I get the
> following errors coming from xerces (linkage errors). thanks for your
> patience !

Uh, I am afraid you will need to rebuild Xerces-C++. The one that
you just built is for Mingw (native Win32). You need one for
Cygwin because you are building XSD examples as Cygwin applications.

I suggest you unpack a fresh copy of Xerces-C++ source somewhere,
set XERCESCROOT and then use the following command lines to configure
and build:

$ ./runConfigure -p cygwin -c gcc -x g++
$ make

Let me know how it goes.

hth,
-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/20060804/82105733/attachment.pgp
From jvdoever at gmail.com  Sun Aug  6 17:57:52 2006
From: jvdoever at gmail.com (Jos van den Oever)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] using xsd in community applications
Message-ID: <c2dbc4260608061457id3c2164r49becbdec93b6a82@mail.gmail.com>

Hello Boris,

I've discovered xsd today and I really like it. The wait for such a
library for Free Software was long but I'm glad it's there. I've tried
my hand at a simple version of this functionality in the past and
found that it is not trivial at all, so my respect for your
achievement is great.

The documentation is pretty extensive, but as a novice with the
library I did have some startup difficulties in constructing and
serializing objects. I've attached an archive with the steps that I
took in extending the example to the functionality I wanted.

I've also written about the experience here:
http://www.kdedevelopers.org/node/2223

I'm sure you like feedback so here are a few suggestions for features
that would be useful for the project I'm working on:
- disabling unneeded (de)serialization options
- no #include but code directly in the header so other developers and
especially testers do not need to install xsd themselves

Basically, anything that reduces binary size is welcome, since the
ease of use of xsd does come at a price in code size.

Still overall very cool and a great timesaver.

Cheers,
Jos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xsdtest.tar.bz2
Type: application/x-bzip2
Size: 156913 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060806/64ebed6d/xsdtest.tar.bin
From katakombi at gmail.com  Mon Aug  7 10:48:22 2006
From: katakombi at gmail.com (Stefan Kombrink)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] support of GML schemes?
Message-ID: <3f6a1ade0608070748g61580c26w335e4e1a33b8663@mail.gmail.com>

Hi everyone,

referring to this post
http://codesynthesis.com/pipermail/xsd-users/2005-October/000063.html
from last autumn I just wanted to ask if the aforementioned issues with the
GML schemes has been fixed already?
Is xsd/xerces a good choice to write a (slick) GML parser?

thanks,
  Stefan >8^)

From boris at codesynthesis.com  Mon Aug  7 14:31:47 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] using xsd in community applications
In-Reply-To: <c2dbc4260608061457id3c2164r49becbdec93b6a82@mail.gmail.com>
References: <c2dbc4260608061457id3c2164r49becbdec93b6a82@mail.gmail.com>
Message-ID: <20060807183147.GB31884@karelia>

Hi Jos,

Jos van den Oever <jvdoever@gmail.com> writes:

> I've discovered xsd today and I really like it. The wait for such a
> library for Free Software was long but I'm glad it's there. I've tried
> my hand at a simple version of this functionality in the past and
> found that it is not trivial at all, so my respect for your
> achievement is great.

Thanks for the kind words ;-).


> The documentation is pretty extensive, but as a novice with the
> library I did have some startup difficulties in constructing and
> serializing objects. I've attached an archive with the steps that I
> took in extending the example to the functionality I wanted.

Nice. BTW, did you look at the library example or did you figure
out serialization by reading the manual?


> I've also written about the experience here:
> http://www.kdedevelopers.org/node/2223

Great stuff! I've added this link to the Resources section of the
C++/Tree mapping page:

http://codesynthesis.com/products/xsd/c++/tree/


> I'm sure you like feedback so here are a few suggestions for features
> that would be useful for the project I'm working on:
> - disabling unneeded (de)serialization options

Serialization is already optional. And I think it is an excellent idea
to make parsing optional as well. I will try to implement this for the
next version.


> - no #include but code directly in the header so other developers and
> especially testers do not need to install xsd themselves

Hm, I am not sure I understand what you mean. Are you suggesting that
we generate runtime code that is included from libxsd "inline" in the
header file? I don't think this is practical because there could be
(and often are) multiple schema files that are compiled separately.
With your suggestion you will end up with the same code in every
header file which will result in re-definition unless properly
guarded.

Since libxsd is a header-only library, you can include it in your
program's source code. This way others don't need to install XSD
(as long as you also ship generated code, of course).


> Basically, anything that reduces binary size is welcome, since the
> ease of use of xsd does come at a price in code size.

Right. We've done a number of optimizations already. The only other
thing that I can think of at the moment is to make more things
optional, as you suggested for the parsing code.


Thanks again for the suggestions and for documenting your experience.


-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/20060807/64bd460f/attachment.pgp
From boris at codesynthesis.com  Mon Aug  7 15:06:35 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] support of GML schemes?
In-Reply-To: <3f6a1ade0608070748g61580c26w335e4e1a33b8663@mail.gmail.com>
References: <3f6a1ade0608070748g61580c26w335e4e1a33b8663@mail.gmail.com>
Message-ID: <20060807190635.GD31884@karelia>

Hi Stefan,

Stefan Kombrink <katakombi@gmail.com> writes:

> referring to this post
> http://codesynthesis.com/pipermail/xsd-users/2005-October/000063.html
> from last autumn I just wanted to ask if the aforementioned issues with the
> GML schemes has been fixed already?

The number of issues depend on what mapping you are planning to use.

The Xerces-C++ bug is still not fixed. Seeing that this questions comes
up at least once a month, I will try to come up with a fix. Meantime
you may want to try GML 3.1.1s which is (quoting from the readme.txt):

"a version of the GML 3.1.1 schema with all "deprecated" components
 removed. This copy of the schema is provided for convenience in
 developing new application schemata to ensure that they do not use
 any deprecated components."

It compiles cleanly with XSD. Pleas see the following post for details:

http://codesynthesis.com/pipermail/xsd-users/2006-July/000445.html
http://codesynthesis.com/pipermail/xsd-users/2006-July/000446.html
http://codesynthesis.com/pipermail/xsd-users/2006-July/000447.html


> Is xsd/xerces a good choice to write a (slick) GML parser?

Looking at all the bloat in GML schemas I am wondering how slick
event a completely hand-crafted parser could be ;-). I think if
you stick to 3.1.1s you might have a chance.


hth,
-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/20060807/475b2479/attachment.pgp
From Remsy.Schmilinsky at ccra-adrc.gc.ca  Tue Aug  8 09:10:00 2006
From: Remsy.Schmilinsky at ccra-adrc.gc.ca (Schmilinsky, Remsy)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] cannot compile hello cygwin
Message-ID: <D46B9A114A1DAD48B88719C1C1043D80039FE682@sh24x696.rc.gc.ca>

Hi Boris. I rebuilt xerces as you recommended. Do I need to recreate the
rest of the packages too? I noticed it built the dll, but not the static
library.

thanks,

Remsy

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com]
Sent: August 4, 2006 3:00 PM
To: Schmilinsky, Remsy
Cc: xsd-users@codesynthesis.com
Subject: Re: [xsd-users] cannot compile hello cygwin


Hi Remsy,

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> Ok, so I had to copy the xerces folder and xsd (the .h files) to
> /usr/include, also libxerces-c.a into /usr/lib. At the end, I get the
> following errors coming from xerces (linkage errors). thanks for your
> patience !

Uh, I am afraid you will need to rebuild Xerces-C++. The one that
you just built is for Mingw (native Win32). You need one for
Cygwin because you are building XSD examples as Cygwin applications.

I suggest you unpack a fresh copy of Xerces-C++ source somewhere,
set XERCESCROOT and then use the following command lines to configure
and build:

$ ./runConfigure -p cygwin -c gcc -x g++
$ make

Let me know how it goes.

hth,
-boris


From boris at codesynthesis.com  Tue Aug  8 10:27:17 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] cannot compile hello cygwin
In-Reply-To: <D46B9A114A1DAD48B88719C1C1043D80039FE682@sh24x696.rc.gc.ca>
References: <D46B9A114A1DAD48B88719C1C1043D80039FE682@sh24x696.rc.gc.ca>
Message-ID: <20060808142716.GC3380@karelia>

Hi Remsy,

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> Hi Boris. I rebuilt xerces as you recommended. Do I need to recreate the
> rest of the packages too? I noticed it built the dll, but not the static
> library.

No, you do not need to rebuild XSD. Just use this version of Xerces-C++
to build examples. The reason you need to link differently-build
Xerces-C++ to xsd and the examples is because xsd was built as Mingw
(native Win32) executable while your examples will be Cygwin
executable.

You may want to copy Xerces-C++ headers from the include/ directory to
/usr/local/include and .lib/.dll from lib/ to /usr/local/lib. This way
g++ should find them automatically.


hth,
-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/20060808/2f82bc55/attachment.pgp
From boris at codesynthesis.com  Tue Aug  8 10:29:52 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] Re: using xsd in community applications
In-Reply-To: <c2dbc4260608071650x55b9c488h946104be713b3c0f@mail.gmail.com>
References: <c2dbc4260608061457id3c2164r49becbdec93b6a82@mail.gmail.com>
	<20060807183147.GB31884@karelia>
	<c2dbc4260608071650x55b9c488h946104be713b3c0f@mail.gmail.com>
Message-ID: <20060808142952.GD3380@karelia>


Hi Jos,

I've CC'ed xsd-users back in; someone might find this information useful.

Jos van den Oever <jvdoever@gmail.com> writes:

> I thinks this example:
>
> ...
>
> should be in the manual.

Added to my TODO list, thanks.


> What i meant was not to disable serialization entirely but to have
> e.g. only iostream serialization. I don't know how this will affect
> code source though.

The core of the serialization (and parsing) uses Xerces streams.
Everything else are just thin wrappers around that. I also think
that most people will prefer to use either URL or std stream for
i/o.


> There may be other possible gains. E.g. adding a
> constant for each string esp. namespace URL. There pop up in a lot of
> places. It would be nice if one could just refer to a constant there.

I also thought string constants will have significant impact on code
size. Then I performed detailed analysis of the object code with nm.
As it turns out, the string constant size is negligible compared to
the text (executable code) size.


> That's true, it's almost 7k in headers. Thats very doable. I didn't
> actually check the header sizes. They're very small. Amazing concept
> by the way, header-only library.

You can further reduce the libxsd size by removing the C++/Parser
mapping runtime (the 'parser' directory) since you are not using it.


> Maybe you could headers to fit an xsd on demand. Just include what's
> required.

It is already done like this. Each optional feature (e.g., serialization)
has a set of headers that are only included if the feature is used.


> I don't know exactly where the size comes from, but the simple example
> above gives a binary of 123k (-Os) which is quite large.

I did a quick test on the hello example from the distribution. I used
g++ 4.1 on a 64 bit machine. Here are the results:

92846  -Os
84396  -O3
60848  stripped -O3

I also examined the symbols with nm (nm -C --print-size --sort-size).
Most of the code comes from things like exceptions, internal helper
functions, etc. All of them are a once-off upfront cost. In other
words, no matter how big is your schema, you will have a fixed
amount of this service code.


> Another question: is it possible to use XSD under an LGPL license. I'm
> using it in a daemon now, so that's on problem. If I'd like to
> communicate in XML with LGPL client libraries or if e.g. KDE would
> want to use xsd too, LGPL would be required.
> I'm guessing you won't allow this, which is of course fine, just asking.

You can use the generated code and runtime in pretty much any open-source
projects (including LGPL-licensed ones). The compiler itself is GPL-only,
though. See the FLOSS exception on the XSD licensing page[1] for more
information.

[1] http://codesynthesis.com/products/xsd/license.xhtml


hth,
-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/20060808/91fcb5b2/attachment.pgp
From jvdoever at gmail.com  Tue Aug  8 10:42:58 2006
From: jvdoever at gmail.com (Jos van den Oever)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] Re: using xsd in community applications
In-Reply-To: <20060808142952.GD3380@karelia>
References: <c2dbc4260608061457id3c2164r49becbdec93b6a82@mail.gmail.com>
	<c2dbc4260608071650x55b9c488h946104be713b3c0f@mail.gmail.com>
	<20060808142952.GD3380@karelia>
Message-ID: <200608081642.58747.jvdoever@gmail.com>

Hello Boris,

On Tuesday 08 August 2006 15:53, you wrote:
> > There may be other possible gains. E.g. adding a
> > constant for each string esp. namespace URL. There pop up in a lot of
> > places. It would be nice if one could just refer to a constant there.
>
> I also thought string constants will have significant impact on code
> size. Then I performed detailed analysis of the object code with nm.
> As it turns out, the string constant size is negligible compared to
> the text (executable code) size.

Even if the cost isn't high, it would be useful to have the namespaces as 
public constants in the parser. At the least this would avoid typos in the 
namespaces.

> > That's true, it's almost 7k in headers. Thats very doable. I didn't
> > actually check the header sizes. They're very small. Amazing concept
> > by the way, header-only library.
>
> You can further reduce the libxsd size by removing the C++/Parser
> mapping runtime (the 'parser' directory) since you are not using it.
Ok, I'll do that, thanks.

> > Maybe you could headers to fit an xsd on demand. Just include what's
> > required.
>
> It is already done like this. Each optional feature (e.g., serialization)
> has a set of headers that are only included if the feature is used.

Great.

> > I don't know exactly where the size comes from, but the simple example
> > above gives a binary of 123k (-Os) which is quite large.
>
> I did a quick test on the hello example from the distribution. I used
> g++ 4.1 on a 64 bit machine. Here are the results:
>
> 92846 ?-Os
> 84396 ?-O3
> 60848 ?stripped -O3

Seems 4.1 has nice improvements over 4.0.

> I also examined the symbols with nm (nm -C --print-size --sort-size).
> Most of the code comes from things like exceptions, internal helper
> functions, etc. All of them are a once-off upfront cost. In other
> words, no matter how big is your schema, you will have a fixed
> amount of this service code.

Ok, this is good to know, if this is the case, useage is much more acceptable.

> > Another question: is it possible to use XSD under an LGPL license. I'm
> > using it in a daemon now, so that's on problem. If I'd like to
> > communicate in XML with LGPL client libraries or if e.g. KDE would
> > want to use xsd too, LGPL would be required.
> > I'm guessing you won't allow this, which is of course fine, just asking.
>
> You can use the generated code and runtime in pretty much any open-source
> projects (including LGPL-licensed ones). The compiler itself is GPL-only,
> though. See the FLOSS exception on the XSD licensing page[1] for more
> information.
>
> [1] http://codesynthesis.com/products/xsd/license.xhtml

Great. This FLOSS exception ( i did ?not read it properly before ) is a very 
good idea and a good way of bypassing the license incompatibilities. So if I 
understand correctly, it's ok to use as long as a significant amount of code 
under any of the FLOSS licenses is used. That's wonderful.

Thanks again for your answers,
Jos


From Remsy.Schmilinsky at ccra-adrc.gc.ca  Tue Aug  8 10:45:04 2006
From: Remsy.Schmilinsky at ccra-adrc.gc.ca (Schmilinsky, Remsy)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] cannot compile hello cygwin
Message-ID: <D46B9A114A1DAD48B88719C1C1043D80039FE68A@sh24x696.rc.gc.ca>

Ok, it compiles and outputs the lines below. When I run driver.exe, it
doesn't do anything. Maybe I missed something...

$ g++ -o driver driver.cxx -I/usr/src/xsd-2.2.0/libxsd
-I/usr/local/include -L/usr/local/lib -lxerces-c

Info: resolving xercesc_2_7::XMLUni::fgXercescDefaultLocale       by
linking to __imp___ZN11xercesc_2_76XMLUni22fgXercescDefau
ltLocaleE (auto-import)
Info: resolving xercesc_2_7::XMLPlatformUtils::fgMemoryManager        by
linking to __imp___ZN11xercesc_2_716XMLPlatformUtils1
5fgMemoryManagerE (auto-import)
Info: resolving xercesc_2_7::XMLUni::fgSAX2CoreNameSpaces       by
linking to __imp___ZN11xercesc_2_76XMLUni20fgSAX2CoreNameSp
acesE (auto-import)
Info: resolving xercesc_2_7::XMLUni::fgSAX2CoreNameSpacePrefixes
by linking to __imp___ZN11xercesc_2_76XMLUni27fgSAX2Cor
eNameSpacePrefixesE (auto-import)
Info: resolving xercesc_2_7::XMLUni::fgXercesValidationErrorAsFatal
by linking to __imp___ZN11xercesc_2_76XMLUni30fgXerc
esValidationErrorAsFatalE (auto-import)
Info: resolving xercesc_2_7::XMLUni::fgSAX2CoreValidation       by
linking to __imp___ZN11xercesc_2_76XMLUni20fgSAX2CoreValida
tionE (auto-import)
Info: resolving xercesc_2_7::XMLUni::fgXercesSchema       by linking to
__imp___ZN11xercesc_2_76XMLUni14fgXercesSchemaE (auto-
import)
Info: resolving xercesc_2_7::XMLUni::fgXercesSchemaFullChecking       by
linking to __imp___ZN11xercesc_2_76XMLUni26fgXercesSc
hemaFullCheckingE (auto-import)
Info: resolving
xercesc_2_7::XMLUni::fgXercesSchemaExternalSchemaLocation       by
linking to __imp___ZN11xercesc_2_76XMLUni36
fgXercesSchemaExternalSchemaLocationE (auto-import)
Info: resolving
xercesc_2_7::XMLUni::fgXercesSchemaExternalNoNameSpaceSchemaLocation
by linking to __imp___ZN11xercesc_2
_76XMLUni47fgXercesSchemaExternalNoNameSpaceSchemaLocationE
(auto-import)

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com]
Sent: August 8, 2006 10:27 AM
To: Schmilinsky, Remsy
Cc: xsd-users@codesynthesis.com
Subject: Re: [xsd-users] cannot compile hello cygwin


Hi Remsy,

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> Hi Boris. I rebuilt xerces as you recommended. Do I need to recreate
the
> rest of the packages too? I noticed it built the dll, but not the
static
> library.

No, you do not need to rebuild XSD. Just use this version of Xerces-C++
to build examples. The reason you need to link differently-build
Xerces-C++ to xsd and the examples is because xsd was built as Mingw
(native Win32) executable while your examples will be Cygwin
executable.

You may want to copy Xerces-C++ headers from the include/ directory to
/usr/local/include and .lib/.dll from lib/ to /usr/local/lib. This way
g++ should find them automatically.


hth,
-boris


From micron at madlab.it  Tue Aug  8 14:49:40 2006
From: micron at madlab.it (Flavio Castelli)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] linux ppc xsd binary missing
Message-ID: <200608082049.41249.micron@madlab.it>

Hello I would really appreciate a linux ppc binary of xsd.

Thanks in advance
	Flavio Castelli
-- 
|? micron<- ICQ #118796665
|? GPG Key:
|?  ~ Keyserver: pgp.mit.edu
|?  ~ KeyID: 6D632BED

~ "Progress is merely a realisation of utopias" ~


From boris at codesynthesis.com  Wed Aug  9 07:06:28 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] xsd-2.2.0-powerpc-linux-gnu released
Message-ID: <20060809110628.GA6217@karelia>


Hi,

We've released a precompiled binary of XSD for GNU/Linux on PowerPC.
It be downloaded from the usual place:

http://codesynthesis.com/products/xsd/download.xhtml

The SHA1 checksum for the file is as follows:

599fc5f5bd129eb004551e2183bd992d7d4dfa38  xsd-2.2.0-powerpc-linux-gnu.tar.bz2


have fun,
-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/20060809/0ef1849f/attachment.pgp
From boris at codesynthesis.com  Wed Aug  9 07:29:07 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] Re: using xsd in community applications
In-Reply-To: <200608081642.58747.jvdoever@gmail.com>
References: <c2dbc4260608061457id3c2164r49becbdec93b6a82@mail.gmail.com>
	<c2dbc4260608071650x55b9c488h946104be713b3c0f@mail.gmail.com>
	<20060808142952.GD3380@karelia>
	<200608081642.58747.jvdoever@gmail.com>
Message-ID: <20060809112907.GC6217@karelia>

Hi Jos,

Thanks for re-posting it to xsd-users.

Jos van den Oever <jvdoever@gmail.com> writes:

> Even if the cost isn't high, it would be useful to have the namespaces as
> public constants in the parser. At the least this would avoid typos in the
> namespaces.

This is true. There are, however, other things to consider. For example,
any extraneous (wrt XML Schema) name introduced into a namespace will
potentially conflict with names used for types and functions. So we will
need to analyze the schema and use name escaping to avoid conflicts.
Things get even more complicated when you start considering multiple
schemas that use the same namespace name. In this case it is really
non-trivial to avoid redefinition. So to summarize, there are two
issues that need to be resolved:

1. How to avoid conflicts with (potentially not yet seen) types and
   functions.

2. How to avoid redefinition with multiple schema files.


> > You can use the generated code and runtime in pretty much any open-source
> > projects (including LGPL-licensed ones). The compiler itself is GPL-only,
> > though. See the FLOSS exception on the XSD licensing page[1] for more
> > information.
> >
> > [1] http://codesynthesis.com/products/xsd/license.xhtml
>
> Great. This FLOSS exception ( i did ?not read it properly before ) is a very
> good idea and a good way of bypassing the license incompatibilities. So if I
> understand correctly, it's ok to use as long as a significant amount of code
> under any of the FLOSS licenses is used. That's wonderful.

It requires that the generated code your license under the FLOSS exception
is actually used by some other code in the open-source project (as opposed
to being there just to change the license from the GPL to a more liberal
one).


hth,
-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/20060809/ca08af46/attachment.pgp
From Remsy.Schmilinsky at ccra-adrc.gc.ca  Wed Aug  9 08:06:51 2006
From: Remsy.Schmilinsky at ccra-adrc.gc.ca (Schmilinsky, Remsy)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] mingw instead of cygwin
Message-ID: <D46B9A114A1DAD48B88719C1C1043D80039FE692@sh24x696.rc.gc.ca>

Hi Boris. What about MinGW? WIll it compile and work on this platform? I tried to compile "build" and it failed.

thanks,

Remsy

From dmitry.trifilov at 121media.com  Wed Aug  9 09:40:54 2006
From: dmitry.trifilov at 121media.com (Dmitry Trifilov)
Date: Sun Oct 11 15:33:47 2009
Subject: [xsd-users] Some performance problems with XSD.
Message-ID: <44D9E5E6.2060105@121media.com>

Hello,
I have some performance problems with code generated by XSD.

Code generated by XSD parses my XML file during 35 - 40 seconds, this 
time is too long for my task.
My XML file have one feature: It contains element "<words_sequence>" 
which contains about 6000 subelements "<Word>".

I use flag "xml_schema::flags::dont_validate" during parsing.
I have foound out that control flow spends a lot of time within function
"void WordsSequence::parse (::xsd::cxx::xml::dom::element< char > const& 
e,  ::xsd::cxx::tree::flags f)" from
KMParsingSettingsSchema.cpp generated by XSD.

I have created simple test which parses my XML file using xerces and 
puts content of  "<Word>" elements to "std::vector<std::string>"
object and I have found out that test works approximately for 2 seconds.

(XSD schema and XML file are gzipped and attached).

My environment is:
Xerces version is "2.6.0".
XSD version is "2.1.0"
gcc compiler version is "Red Hat Linux 3.2.3-54"

I am not familiar with XML schemas, may be it is my bag in XML schema 
definition?
How can I improve performance and where is the source of my performance 
problems?

Thanks in advance
-Dmitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: KMParsingSettingsSchema_xsd.tgz
Type: application/octet-stream
Size: 1043 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060809/012a25ed/KMParsingSettingsSchema_xsd.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KMParsingSettingsSchema_xml.tgz
Type: application/octet-stream
Size: 47960 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060809/012a25ed/KMParsingSettingsSchema_xml.obj
From boris at codesynthesis.com  Wed Aug  9 11:27:42 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] cannot compile hello cygwin
In-Reply-To: <D46B9A114A1DAD48B88719C1C1043D80039FE68A@sh24x696.rc.gc.ca>
References: <D46B9A114A1DAD48B88719C1C1043D80039FE68A@sh24x696.rc.gc.ca>
Message-ID: <20060809152742.GB6511@karelia>

Hi Remsy,

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> Ok, it compiles and outputs the lines below. When I run driver.exe, it
> doesn't do anything. Maybe I missed something...

I tried to build Xerces-C++ 2.7.0 for Cygwin and then build examples
from the xsd-2.2.0 distribution for Windows. Everyhting worked fine
with examples printing what they were supposed to print. Here is a
step-by-step instructions. Can you try them and see if it works for
you:

1. Download, unpack and build Xerces-C++ 2.7.0:

$ cd ~
$ wget http://www.apache.org/dist/xml/xerces-c/source/xerces-c-src_2_7_0.tar.gz
$ gzip -dc xerces-c-src_2_7_0.tar.gz | tar x
$ export XERCESCROOT=~/xerces-c-src_2_7_0
$ cd xerces-c-src_2_7_0/src/xerces
$ ./runConfigure -p cygwin -c gcc -x g++
$ make


2. Download, unpack and build XSD 2.2.0 examples:

$ cd ~
$ wget http://codesynthesis.com/download/xsd/2.2/windows/i686/xsd-2.2.0-i686-windows.zip
$ unzip xsd-2.2.0-i686-windows.zip
$ cd xsd-2.2.0-i686-windows/examples/cxx/tree/hello
$ make CPPFLAGS="-I ~/xerces-c-src_2_7_0/include" LDFLAGS="-L ~/xerces-c-src_2_7_0/lib"
$ export PATH=~/xerces-c-src_2_7_0/lib:$PATH
$ ./driver hello.xml


For me the last line prints:

Hello, sun!
Hello, moon!
Hello, world!


hth,
-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/20060809/2662d9e1/attachment.pgp
From boris at codesynthesis.com  Wed Aug  9 11:45:34 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] Re: Problem with XSD
In-Reply-To: <44d9934fe960b@wp.pl>
References: <44d9934fe960b@wp.pl>
Message-ID: <20060809154534.GC6511@karelia>

Hi Tomasz,

Please send technical questions about XSD to the xsd-users mailing
list (which I've CC'ed to my reply). This way other will be able to
help you as well as to benefit from the discussion.


Tomasz Kowalski <tomi707@wp.pl> writes:

> I downloaded Your example file for XSD - hello.xsd.
> When I try change this file to C++ (xsd cxx-tree hello.xsd) 'xsd'
> program gives me 2 files - hello.cxx and hello.hxx.
>
> When I try to compile this file I have linker errors.
> In downloaded xerces-c-2.7 are libraries : xerxes-c-2, xerces-c-2D,
> xerces-c_2_7 and xerces-c_2_7D. I include this libraries.
>
> In manual cxx-tree-manual.pdf I found example, where for compiling
> hello.cxx is include xerces-c. But I haven't this library.

The example in the manual uses UNIX way of building things. Seeing
that you've downloaded precompiled libraries of Xerces-C++ for
Windows, I assume you are using Windows and Visual C++. The XSD
distribution for Windows[2] includes Visual C++ project files
for all examples, including 'hello', which is presented in the
manual. Please read the accompanying README file for the
instructions on how to set everything up.


[1] http://codesynthesis.com/mailman/listinfo/xsd-users
[2] http://codesynthesis.com/products/xsd/download.xhtml


hth,
-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/20060809/97b0cb84/attachment.pgp
From Remsy.Schmilinsky at ccra-adrc.gc.ca  Wed Aug  9 11:49:19 2006
From: Remsy.Schmilinsky at ccra-adrc.gc.ca (Schmilinsky, Remsy)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] cannot compile hello cygwin
Message-ID: <D46B9A114A1DAD48B88719C1C1043D80039FE698@sh24x696.rc.gc.ca>

It finally worked, thanks ! but I still got these messages...maybe they
could dissapear by rebuilding xsd.exe again with the new compilation of
xerces. I'll try later...

Remsy

$ make CPPFLAGS="-I ~/xerces-c-src_2_7_0/include" LDFLAGS="-L
~/xerces-c-src_2_7_0/lib"
../../../../bin/xsd cxx-tree  hello.xsd
g++ -I ~/xerces-c-src_2_7_0/include -I../../../../libxsd -W -Wall -c
driver.cxx -o driver.o
g++ -I ~/xerces-c-src_2_7_0/include -I../../../../libxsd -W -Wall -c
hello.cxx -o hello.o
g++ -W -Wall -L ~/xerces-c-src_2_7_0/lib -o driver driver.o hello.o
-lxerces-c
Info: resolving xercesc_2_7::XMLUni::fgXercescDefaultLocale       by
linking to __imp___ZN11xercesc_2_76XMLUni22fgXercescDefau
ltLocaleE (auto-import)
Info: resolving xercesc_2_7::XMLPlatformUtils::fgMemoryManager        by
linking to __imp___ZN11xercesc_2_716XMLPlatformUtils1
5fgMemoryManagerE (auto-import)
Info: resolving xercesc_2_7::XMLUni::fgDOMComments       by linking to
__imp___ZN11xercesc_2_76XMLUni13fgDOMCommentsE (auto-im
port)
Info: resolving xercesc_2_7::XMLUni::fgDOMDatatypeNormalization       by
linking to __imp___ZN11xercesc_2_76XMLUni26fgDOMDatat
ypeNormalizationE (auto-import)
Info: resolving xercesc_2_7::XMLUni::fgDOMEntities       by linking to
__imp___ZN11xercesc_2_76XMLUni13fgDOMEntitiesE (auto-im
port)
Info: resolving xercesc_2_7::XMLUni::fgDOMNamespaces       by linking to
__imp___ZN11xercesc_2_76XMLUni15fgDOMNamespacesE (aut
o-import)
Info: resolving xercesc_2_7::XMLUni::fgDOMWhitespaceInElementContent
by linking to __imp___ZN11xercesc_2_76XMLUni31fgDOM
WhitespaceInElementContentE (auto-import)
Info: resolving xercesc_2_7::XMLUni::fgDOMValidation       by linking to
__imp___ZN11xercesc_2_76XMLUni15fgDOMValidationE (aut
o-import)
Info: resolving xercesc_2_7::XMLUni::fgXercesSchema       by linking to
__imp___ZN11xercesc_2_76XMLUni14fgXercesSchemaE (auto-
import)
Info: resolving xercesc_2_7::XMLUni::fgXercesSchemaFullChecking       by
linking to __imp___ZN11xercesc_2_76XMLUni26fgXercesSc
hemaFullCheckingE (auto-import)
Info: resolving xercesc_2_7::XMLUni::fgXercesUserAdoptsDOMDocument
by linking to __imp___ZN11xercesc_2_76XMLUni29fgXerce
sUserAdoptsDOMDocumentE (auto-import)
Info: resolving
xercesc_2_7::XMLUni::fgXercesSchemaExternalSchemaLocation       by
linking to __imp___ZN11xercesc_2_76XMLUni36
fgXercesSchemaExternalSchemaLocationE (auto-import)
Info: resolving
xercesc_2_7::XMLUni::fgXercesSchemaExternalNoNameSpaceSchemaLocation
by linking to __imp___ZN11xercesc_2
_76XMLUni47fgXercesSchemaExternalNoNameSpaceSchemaLocationE
(auto-import)

~/xsd-2.2.0-i686-windows/examples/cxx/tree/hello
$ ls
README      driver.exe  hello.cxx  hello.o       hello.xml  makefile
driver.cxx  driver.o    hello.hxx  hello.vcproj  hello.xsd
makefile.vc-7

~/xsd-2.2.0-i686-windows/examples/cxx/tree/hello
$ export PATH=~/xerces-c-src_2_7_0/lib:$PATH

~/xsd-2.2.0-i686-windows/examples/cxx/tree/hello
$ ./driver hello.xml
Hello, sun!
Hello, moon!
Hello, world!

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com]
Sent: August 9, 2006 11:28 AM
To: Schmilinsky, Remsy
Cc: xsd-users@codesynthesis.com
Subject: Re: [xsd-users] cannot compile hello cygwin


Hi Remsy,

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> Ok, it compiles and outputs the lines below. When I run driver.exe, it
> doesn't do anything. Maybe I missed something...

I tried to build Xerces-C++ 2.7.0 for Cygwin and then build examples
from the xsd-2.2.0 distribution for Windows. Everyhting worked fine
with examples printing what they were supposed to print. Here is a
step-by-step instructions. Can you try them and see if it works for
you:

1. Download, unpack and build Xerces-C++ 2.7.0:

$ cd ~
$ wget
http://www.apache.org/dist/xml/xerces-c/source/xerces-c-src_2_7_0.tar.gz
$ gzip -dc xerces-c-src_2_7_0.tar.gz | tar x
$ export XERCESCROOT=~/xerces-c-src_2_7_0
$ cd xerces-c-src_2_7_0/src/xerces
$ ./runConfigure -p cygwin -c gcc -x g++
$ make


2. Download, unpack and build XSD 2.2.0 examples:

$ cd ~
$ wget
http://codesynthesis.com/download/xsd/2.2/windows/i686/xsd-2.2.0-i686-wi
ndows.zip
$ unzip xsd-2.2.0-i686-windows.zip
$ cd xsd-2.2.0-i686-windows/examples/cxx/tree/hello
$ make CPPFLAGS="-I ~/xerces-c-src_2_7_0/include" LDFLAGS="-L
~/xerces-c-src_2_7_0/lib"
$ export PATH=~/xerces-c-src_2_7_0/lib:$PATH
$ ./driver hello.xml


For me the last line prints:

Hello, sun!
Hello, moon!
Hello, world!


hth,
-boris


From boris at codesynthesis.com  Wed Aug  9 12:18:42 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] cannot compile hello cygwin
In-Reply-To: <D46B9A114A1DAD48B88719C1C1043D80039FE698@sh24x696.rc.gc.ca>
References: <D46B9A114A1DAD48B88719C1C1043D80039FE698@sh24x696.rc.gc.ca>
Message-ID: <20060809161842.GD6511@karelia>


Hi Remsy,

Schmilinsky, Remsy <Remsy.Schmilinsky@ccra-adrc.gc.ca> writes:

> It finally worked, thanks ! but I still got these messages...

Yes I've got those too. They are informational and I gather have
something to do with the way the Xerces-C++ library was built
(symbol auto importing/exporting). I am not exactly sure how
to get rid of them other than re-creating Xerces-C++ as a static
library. I just tried this and it works:

$ cd ~
$ cd xerces-c-src_2_7_0/lib
$ rm *
$ ar rc libxerces-c.a ../obj/CYGWIN/*.o
$ ranlib libxerces-c.a

This gets rid of the Info messages and makes fiddling with PATH
unnecessary.


> maybe they could dissapear by rebuilding xsd.exe again with the new
> compilation of xerces.

No this definitely won't help.


hth,
-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/20060809/266f25c2/attachment.pgp
From boris at codesynthesis.com  Thu Aug 10 06:17:47 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] Some performance problems with XSD.
In-Reply-To: <44D9E5E6.2060105@121media.com>
References: <44D9E5E6.2060105@121media.com>
Message-ID: <20060810101747.GA4173@karelia>

Hi Dmitry,

Dmitry Trifilov <dmitry.trifilov@121media.com> writes:

> I have some performance problems with code generated by XSD.
>
> Code generated by XSD parses my XML file during 35 - 40 seconds, this
> time is too long for my task.
> My XML file have one feature: It contains element "<words_sequence>"
> which contains about 6000 subelements "<Word>".

Thanks for providing the test case. I investigated the problem and
created a patch[1]. Simply replace the files in your copy of libxsd
with the ones supplied. The changes are compatible with 2.2.0. They
will most likely work with 2.1.0, though there is no guarantee.

On my box the time when from about 160s to 0.12s. For those interested,
the Xerces-C++ DOMNodeList implementation has O(n) access time. Replacing
it with getFirstChild/getNextSibling speeds things up significantly.

Thanks for reporting this!

[1] http://codesynthesis.com/~boris/tmp/xsd-2.2.0-performance-patch.tar.gz

hth,
-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/20060810/d0567164/attachment.pgp
From douglas.chappelle at siemens.com  Wed Aug 16 10:54:58 2006
From: douglas.chappelle at siemens.com (Chappelle, Douglas (Com US))
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] How to create an object from the xml data without
	knowing the element type?
Message-ID: <34003F6AC0C35F41B51CE9F34885843308CE4E4F@USNWK101MSX.ww017.siemens.net>

Hello,
 
I'm new to XSD. Is there a way to create an object from the xml data
without knowing the element type? If not, how is this usually handled -
in particular - how do I find the object type? In my example I can
receive hundreds of different objects but would like to avoid creating
some sort of object factory to figure out what object it is and
instantiate it. 
 
Thanks in advance,
Doug
 

From boris at codesynthesis.com  Wed Aug 16 11:43:39 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] How to create an object from the xml data without
	knowing the element type?
In-Reply-To: <34003F6AC0C35F41B51CE9F34885843308CE4E4F@USNWK101MSX.ww017.siemens.net>
References: <34003F6AC0C35F41B51CE9F34885843308CE4E4F@USNWK101MSX.ww017.siemens.net>
Message-ID: <20060816154339.GA17011@karelia>

Hi Doug,

Chappelle, Douglas (Com US) <douglas.chappelle@siemens.com> writes:

> I'm new to XSD. Is there a way to create an object from the xml data
> without knowing the element type?

No, there is no such facility in XSD. Even if there was then it
is not clear how it would be useful. Imagine there is a generic
function parse() that takes XML document and returns the in-memory
representation. Since it can not assume anything about the type, it
returns generic xml_schema::type which is a base for all generated
types. The question is then what useful things can you do with an
instance of static type xml_schema::type if you have no idea about
its dynamic type and therefore cannot cast it to anything useful?


> If not, how is this usually handled - in particular - how do I find
> the object type? In my example I can receive hundreds of different
> objects but would like to avoid creating some sort of object factory
> to figure out what object it is and instantiate it.

I think the most straightforward way to handle XML that can be of
one of several predefined types is to peek at the root element and
then use the appropriate parsing function. Suppose we have two root
elements defined in the schema: foo and bar with types Foo and Bar
respectively, then you code could look like this:

using namespace xercesc;

DOMDocument* dom = ... // Parse XML into DOM.
DOMElement* root = dom->getDocumentElement ();
std::string name (xsd::cxx::xml::transcode (root->getLocalName ()));

if (name == "foo")
{
  std::auto_ptr<Foo> f (foo (*dom)); // Parse dom to Foo.

  // Do something useful with f.
}
else if (name == "bar")
{
  std::auto_ptr<Bar> b (bar (*dom)); // Parse dom to Bar.

  // Do something useful with b.
}


If you do not worry about performance much, you can just try calling
each parsing function in a sequence; all except one will fail:

while (true)
{
  try
  {
    std::auto_ptr<Foo> f (foo (*dom)); // Try to parse dom to Foo.

    // Do something useful with f.
    break;
  }
  catch (xml_schema::unexpected_element const&)
  {
    // Try the next function.
  }

  try
  {
    std::auto_ptr<Bar> b (bar (*dom)); // Try to parse dom to Bar.

    // Do something useful with b.
    break;
  }
  catch (xml_schema::unexpected_element const&)
  {
    // Try the next function.
  }
}

hth,
-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/20060816/8e70f79c/attachment.pgp
From douglas.chappelle at siemens.com  Thu Aug 17 15:37:43 2006
From: douglas.chappelle at siemens.com (Chappelle, Douglas (Com US))
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] How to create an object from the xml data without
	knowing the element type?
Message-ID: <34003F6AC0C35F41B51CE9F34885843308F6D304@USNWK101MSX.ww017.siemens.net>


Thanks for the quick response, it was very helpful!

A couple more questions..

[1] I have an object factory that returns auto_ptr<type> (type of course
being the base type of the xsd objects created). Is there an easy way
(api) to find out what element this is?

For example:

     auto_ptr<type> obj;
     obj = myXsdObject(xml_data);
     obj->? Returns "myXsdObject"

[2] I'm reading through the Tree User manual looking for an easy way to
serialize an auto_ptr<type> to an output stream. I see section 4.5
Serializing to std::ostream but is there a way to do this without
needing to build a namespace infomap? 

Thanks again,
Doug

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Wednesday, August 16, 2006 11:44 AM
To: Chappelle, Douglas (Com US)
Cc: xsd-users@codesynthesis.com
Subject: Re: [xsd-users] How to create an object from the xml data
without knowing the element type?

Hi Doug,

Chappelle, Douglas (Com US) <douglas.chappelle@siemens.com> writes:

> I'm new to XSD. Is there a way to create an object from the xml data
> without knowing the element type?

No, there is no such facility in XSD. Even if there was then it
is not clear how it would be useful. Imagine there is a generic
function parse() that takes XML document and returns the in-memory
representation. Since it can not assume anything about the type, it
returns generic xml_schema::type which is a base for all generated
types. The question is then what useful things can you do with an
instance of static type xml_schema::type if you have no idea about
its dynamic type and therefore cannot cast it to anything useful?


> If not, how is this usually handled - in particular - how do I find
> the object type? In my example I can receive hundreds of different
> objects but would like to avoid creating some sort of object factory
> to figure out what object it is and instantiate it.

I think the most straightforward way to handle XML that can be of
one of several predefined types is to peek at the root element and
then use the appropriate parsing function. Suppose we have two root
elements defined in the schema: foo and bar with types Foo and Bar
respectively, then you code could look like this:

using namespace xercesc;

DOMDocument* dom = ... // Parse XML into DOM.
DOMElement* root = dom->getDocumentElement ();
std::string name (xsd::cxx::xml::transcode (root->getLocalName ()));

if (name == "foo")
{
  std::auto_ptr<Foo> f (foo (*dom)); // Parse dom to Foo.

  // Do something useful with f.
}
else if (name == "bar")
{
  std::auto_ptr<Bar> b (bar (*dom)); // Parse dom to Bar.

  // Do something useful with b.
}


If you do not worry about performance much, you can just try calling
each parsing function in a sequence; all except one will fail:

while (true)
{
  try
  {
    std::auto_ptr<Foo> f (foo (*dom)); // Try to parse dom to Foo.

    // Do something useful with f.
    break;
  }
  catch (xml_schema::unexpected_element const&)
  {
    // Try the next function.
  }

  try
  {
    std::auto_ptr<Bar> b (bar (*dom)); // Try to parse dom to Bar.

    // Do something useful with b.
    break;
  }
  catch (xml_schema::unexpected_element const&)
  {
    // Try the next function.
  }
}

hth,
-boris


From douglas.chappelle at siemens.com  Thu Aug 17 16:55:51 2006
From: douglas.chappelle at siemens.com (Chappelle, Douglas (Com US))
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] a couple of questions
Message-ID: <34003F6AC0C35F41B51CE9F34885843308F6D484@USNWK101MSX.ww017.siemens.net>

Hello,

I have a couple of questions...

[1] I have an object factory that returns auto_ptr<type> (type of course
being the base type of the xsd objects created). Is there an easy way
(api) to find out what element this is?

For example:
	auto_ptr<type> obj;
	obj = myXsdObject(xml_data);
	obj->? Returns "myXsdObject"

[2] I'm reading through the Tree User manual looking for an easy way to
serialize an auto_ptr<type> to an output stream. I see section 4.5
Serializing to std::ostream but is there a way to do this without
needing to build a namespace infomap? 



From boris at codesynthesis.com  Fri Aug 18 14:19:06 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] a couple of questions
In-Reply-To: <34003F6AC0C35F41B51CE9F34885843308F6D484@USNWK101MSX.ww017.siemens.net>
References: <34003F6AC0C35F41B51CE9F34885843308F6D484@USNWK101MSX.ww017.siemens.net>
Message-ID: <20060818181906.GA27730@karelia>

Hi Doug,

Chappelle, Douglas (Com US) <douglas.chappelle@siemens.com> writes:

> [1] I have an object factory that returns auto_ptr<type> (type of course
> being the base type of the xsd objects created). Is there an easy way
> (api) to find out what element this is?
>
> For example:
> 	auto_ptr<type> obj;
> 	obj = myXsdObject(xml_data);
> 	obj->? Returns "myXsdObject"

The same type can be used for more than one element (or even attribute)
so there is no information about this stored by the type itself. You
can, however, use the DOM association feature to obtain this
information. There is the keep_dom flag which you can pass to parsing
functions. You can then use the xml_schema::type::_node member
function to obtain a DOM node that corresponds to this tree node.
Cast it to DOMElement and you can get to the element's name. See
the 'mixed' example for more information on the keep_dom feature.


> [2] I'm reading through the Tree User manual looking for an easy way to
> serialize an auto_ptr<type> to an output stream. I see section 4.5
> Serializing to std::ostream but is there a way to do this without
> needing to build a namespace infomap?

I assume here that you want to serialize auto_ptr<type> generically,
without limiting yourself to some predefined set of types.

There is a way to achieve this though t requires some extra work
from your side. You can serialize an instance of a generated type
to a DOM element (or attribute if it is a simple type). For that
you would use one of the operator<< operators that are generated
when you specify the --generate-serialization option. This implies
that you will need to construct the DOMDocument yourself. If we
have a generated type Foo, then the code would look like this (see
the section 4.1, "Serializing to DOM" of the manual for how to
create a DOMDocument instance):

const Foo& foo = ...

DOMDocument* doc = ... // Create DOM document.
DOMElement* root = doc->getDocumentElement ();

root << foo; // Serialize foo to root.

Now to the tricky part of serializing xml_schema::type instead
of Foo. In order to support XML Schema polymorphism (xsi:type
and substitution groups), XSD generates a map of a type id to
serialization operator for each generated type. This only
happens when you specify the --generate-polymorphic option. The
idea is to take advantage of this map in order to find the
serialization function for instance's dynamic type. Here is the
code that accomplishes this:

auto_ptr<xml_schema::type> t = ...
DOMElement* root = ...

{
  using namespace xsd::cxx::tree;

  typedef type_name_map<char> type_map;
  const type_map& map (type_name_map_instance<0, char> ());

  const type_map::type_info* ti (map.find_type (typeid (*t)));

  if (ti == 0)
  {
    // No type information: compiled without --generate-polymorphic?
  }

  ti->serializer () (root, *t);
}

And the final note: in the current version (2.2.0) both
type_name_map::type_info and type_name_map::find_type are private.
You will need to make them public (in libxsd/xsd/cxx/tree/type-name-map.hxx)
in order for the above code to compile. In the next version of XSD they
will be public.


hth,
-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/20060818/2b1dfed8/attachment.pgp
From gerardlanois at gmail.com  Sun Aug 20 16:54:53 2006
From: gerardlanois at gmail.com (Gerard Lanois)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] How to create an object from the xml data without
	knowing the element type?
In-Reply-To: <20060816154339.GA17011@karelia>
References: <34003F6AC0C35F41B51CE9F34885843308CE4E4F@USNWK101MSX.ww017.siemens.net>
	<20060816154339.GA17011@karelia>
Message-ID: <a8b1fc100608201354r76146b0boecab6f623321b3f9@mail.gmail.com>

On 8/16/06, Boris Kolpackov <boris@codesynthesis.com> wrote:
> using namespace xercesc;
>
> DOMDocument* dom = ... // Parse XML into DOM.
> DOMElement* root = dom->getDocumentElement ();
> std::string name (xsd::cxx::xml::transcode (root->getLocalName ()));
>
> if (name == "foo")
> {
>   std::auto_ptr<Foo> f (foo (*dom)); // Parse dom to Foo.
>
>   // Do something useful with f.
> }
> else if (name == "bar")
> {
>   std::auto_ptr<Bar> b (bar (*dom)); // Parse dom to Bar.
>
>   // Do something useful with b.
> }
>
>
> If you do not worry about performance much, you can just try calling
> each parsing function in a sequence; all except one will fail:
>
> while (true)
> {
>   try
>   {
>     std::auto_ptr<Foo> f (foo (*dom)); // Try to parse dom to Foo.
>
>     // Do something useful with f.
>     break;
>   }
>   catch (xml_schema::unexpected_element const&)
>   {
>     // Try the next function.
>   }
>
>   try
>   {
>     std::auto_ptr<Bar> b (bar (*dom)); // Try to parse dom to Bar.
>
>     // Do something useful with b.
>     break;
>   }
>   catch (xml_schema::unexpected_element const&)
>   {
>     // Try the next function.
>   }
> }

I think this example would be a very useful addition to the
documentation (maybe in in a "beginners" or "getting started"
section).  And perhaps you could expand on the comment above which
states "// Parse XML into DOM."

-Gerard

From boris at codesynthesis.com  Tue Aug 22 07:52:05 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] How to create an object from the xml data without
	knowing the element type?
In-Reply-To: <a8b1fc100608201354r76146b0boecab6f623321b3f9@mail.gmail.com>
References: <34003F6AC0C35F41B51CE9F34885843308CE4E4F@USNWK101MSX.ww017.siemens.net>
	<20060816154339.GA17011@karelia>
	<a8b1fc100608201354r76146b0boecab6f623321b3f9@mail.gmail.com>
Message-ID: <20060822115205.GA5151@karelia>

Hi Gerard,

Gerard Lanois <gerardlanois@gmail.com> writes:

> I think this example would be a very useful addition to the
> documentation (maybe in in a "beginners" or "getting started"
> section). And perhaps you could expand on the comment above which
> states "// Parse XML into DOM."

Yes, that's an excellent idea. I started a Wiki FAQ[1] and added
both of these items to it.

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

-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/20060822/0f585d3d/attachment.pgp
From boris at codesynthesis.com  Tue Aug 22 08:39:52 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] wiki.codesynthesis.com started
Message-ID: <20060822123952.GB5151@karelia>


Hi,

We've started a Wiki (based on MediaWiki[1]) that will hopefully
become a community knowledge base for our various projects. For
XSD we are thinking of maintain informations such as FAQs, post-
release notes, tips for using on various platforms, etc. The
root page for XSD is

http://wiki.codesynthesis.com/XSD

The page that has the most useful information at the moment
is the C++/Tree mapping FAQ:

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

You are welcome to participate in creating and editing the
information. Due to link spam we only allow logged-in users
to edit pages. All information is licensed under the GNU FDL
version 1.2.

[1] http://www.mediawiki.org


have fun,
-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/20060822/cd9f87b9/attachment.pgp
From douglas.chappelle at siemens.com  Tue Aug 22 09:42:24 2006
From: douglas.chappelle at siemens.com (Chappelle, Douglas (Com US))
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] How to create an object from the xml data without
	knowing the element type?
Message-ID: <34003F6AC0C35F41B51CE9F348858433097F0595@USNWK101MSX.ww017.siemens.net>


Thanks, your help was much appreciated. 

-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Tuesday, August 22, 2006 7:52 AM
To: Gerard Lanois
Cc: Chappelle, Douglas (Com US); xsd-users@codesynthesis.com
Subject: Re: [xsd-users] How to create an object from the xml data
without knowing the element type?

Hi Gerard,

Gerard Lanois <gerardlanois@gmail.com> writes:

> I think this example would be a very useful addition to the
> documentation (maybe in in a "beginners" or "getting started"
> section). And perhaps you could expand on the comment above which
> states "// Parse XML into DOM."

Yes, that's an excellent idea. I started a Wiki FAQ[1] and added
both of these items to it.

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

-boris


From Robert.Boucher at ca.com  Tue Aug 22 10:55:20 2006
From: Robert.Boucher at ca.com (Boucher, Robert J)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] C++/Parser: parsing of <xsd:attribute>
Message-ID: <5E0A26D7F3D1264085CCAFFD111C86680155B5E1@USILMS14.ca.com>


Hello!
I have a question on how to properly handle <xsd:attribute> when parsing
a document.  I use the following schema:

	<xsd:complexType name="ItemType">
		<xsd:sequence>
			<xsd:element name="doc" type="xsd:string"
minOccurs="0" maxOccurs="1" />
		</xsd:sequence>
		<xsd:attribute name="name" type="xsd:string"
use="optional" />
		<xsd:attribute name="create" type="xsd:boolean"
use="optional" default="false" />
	</xsd:complexType>

When I generate the templates, I get the following parser hooks in the
ItemType template:
        virtual void pre ();
        virtual void doc (const _xsd_doc_&);
        virtual void name (const _xsd_name_&);
        virtual void create (const _xsd_create_&);
        virtual _xsd_ItemType_ post ();

However, when I use the template and instantiate it, I can see that the
doc() method is called property, but I never see name() or create() get
called.  Tracing the application, I noticed that I can "capture" the
presence of attributes if I provide an implementation of the
_attribute_impl() method.  In my testing, I also note the name() and
create() never get called.

So my question is: what is the proper way of parsing attributes?   Do I
need to implement _attribute_impl() or is there something else I need to
do to have the parser call the name() & create() methods explicitly?

Thank you very much for your time,

Robert B.


From boris at codesynthesis.com  Tue Aug 22 14:23:22 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] C++/Parser: parsing of <xsd:attribute>
In-Reply-To: <5E0A26D7F3D1264085CCAFFD111C86680155B5E1@USILMS14.ca.com>
References: <5E0A26D7F3D1264085CCAFFD111C86680155B5E1@USILMS14.ca.com>
Message-ID: <20060822182322.GA6417@karelia>

Hi Robert,

Boucher, Robert J <Robert.Boucher@ca.com> writes:

> When I generate the templates, I get the following parser hooks in the
> ItemType template:
>         virtual void pre ();
>         virtual void doc (const _xsd_doc_&);
>         virtual void name (const _xsd_name_&);
>         virtual void create (const _xsd_create_&);
>         virtual _xsd_ItemType_ post ();
>
> However, when I use the template and instantiate it, I can see that the
> doc() method is called property, but I never see name() or create() get
> called.  Tracing the application, I noticed that I can "capture" the
> presence of attributes if I provide an implementation of the
> _attribute_impl() method.  In my testing, I also note the name() and
> create() never get called.

There are two most likely causes of this:

1. You did not override the hooks. This usually happens when the
   signatures in the generated parser template and the one you
   use in the implementation do not match:

   struct ItemTypeImpl: ItemType<void,
                                 std::string, // doc
                                 std::string, // name (1)
                                 bool> // create (2)
   {

     // Make sure the type matches (1).
     //
     virtual void name (const std::string&);

     // Make sure the type matches (2).
     //
     virtual void name (const bool&);
   };


2. You did not set the parsers for name and create. Continuing the
   above example, make sure you have something like this in your
   code:

   xml_schema::string string_parser;
   xml_schema::boolean bool_parser;
   ItemTypeImpl item_parser;

   item_parser.doc_parser (string_parser);
   item_parser.name_parser (string_parser);
   item_parser.create_parser (bool_parser);


If none of these help, then we will need a small test case that reproduces
the problem. A schema, a test XML instance and a simple test driver would
be enough.

hth,
-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/20060822/ea68084b/attachment.pgp
From Lawrence.Lifshitz at umassmed.edu  Tue Aug 22 16:14:27 2006
From: Lawrence.Lifshitz at umassmed.edu (Lawrence M. Lifshitz)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] xsd documentation (other than examples) wanted
Message-ID: <44EB65A3.1000602@umassmed.edu>

Hi,
   I'm completely new to xsd and xml in general.  I'm trying to use xsd. I've downloaded
xsd-2.2.0-1.i686.rpm (Fedora Core 4 Linux) and installed it, and compiled the examples.
The only documentation I see is under /usr/doc/xsd/examples  in the form of example
files (and running xsd help).  Is there anything that describes in more detail
how to actually use it?  I'm trying to use it to parse an xsd file which I'm not
very familiar with.

Yes, I know I can look at the hxx, cxx, and txx files produced -
1.  I'm not that expert at C++ to decipher all the layers there
2.  That is a very low level way to learn, useful when one or two problems
      arise that need to be figured out, but sort of looking at the trees instead
     of the forest.

xsd seems like great  software, I'm looking for the great documentation ...

I would think this would be an faq, but I can't find the faq!

Thanks for any pointers.

-- 
Lawrence M. Lifshitz, Ph. D., Associate Professor
Biomedical Imaging Group (http://invitro.umassmed.edu)
University of Massachusetts Medical School (http://www.umassmed.edu)
Phone: (508) 856-3392   email: Lawrence.Lifshitz@umassmed.edu
Fax:   (508) 856-1840     web: http://invitro.umassmed.edu/lml


From boris at codesynthesis.com  Wed Aug 23 04:01:21 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] xsd documentation (other than examples) wanted
In-Reply-To: <44EB65A3.1000602@umassmed.edu>
References: <44EB65A3.1000602@umassmed.edu>
Message-ID: <20060823080121.GA8359@karelia>

Hi Lawrence,

Lawrence M. Lifshitz <Lawrence.Lifshitz@umassmed.edu> writes:

> The only documentation I see is under /usr/doc/xsd/examples  in the form of
> example files (and running xsd help).

This is actually a bug: our RPM spec file does not include documentation
other than the man pages. We will try to fix this for the next version.
Thanks for reporting it!


> Is there anything that describes in more  detail how to actually use it?

Sure. First of all, XSD supports two C++ mappings: C++/Tree and  C++/Parser.

The C++/Tree mapping overview page is here:

http://codesynthesis.com/products/xsd/c++/tree/

It includes a number of resources under the "Documentation" section,
including C++/Tree Quick Guide, C++/Tree User Manual, FAQs, etc.


The C++/Parser mapping overview page is here:

http://codesynthesis.com/products/xsd/c++/parser/

There is also a bunch of links under the "Documentation" section.


To decide which mapping you want I suggest you read quick guides
for both the C++/Tree and C++/Parser mappings; this will give you
an idea about what programming with each mapping feels like.

Let us know if you have any further questions.


hth,
-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/20060823/f96b29e8/attachment.pgp
From boris at codesynthesis.com  Tue Aug 29 14:03:49 2006
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Sun Oct 11 15:33:48 2009
Subject: [xsd-users] Re: XML code generator
In-Reply-To: <7A18022876749344BEAB4702BC63AB1D0337745D@USLV-AEXCH-V1.Aristocrat-inc.com>
References: <7A18022876749344BEAB4702BC63AB1D0337745D@USLV-AEXCH-V1.Aristocrat-inc.com>
Message-ID: <20060829180349.GA8366@karelia>

Hi Jeff,

I've CC'ed xsd-users mailing list to my reply in case somebody has
or will have a similar question.


Gonzales, Jeff <jeff.gonzales@aristocrat-inc.com> writes:

> I have a question about your C++ XML code generator.  Can it manipulate
> XML encoded as a literal string?

Yes, it can do this via std::istringstream. The code would look like
this (based on the hello example):

#include <sstream>

std::istringstream istr ("your XML goes here");

auto_ptr<hello_type> h (hello (istr));


hth,
-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/20060829/78ad88f8/attachment.pgp