From boris at codesynthesis.com  Thu Dec  1 08:16:29 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Dec  1 08:24:28 2011
Subject: [xsde-users] Re: ignoring parts of the schema - and referenced
	schemas
In-Reply-To: <781FA5C8-84E5-41BC-A2F3-487B28CE58BA@csr.com>
References: <54B9B91B-084A-4AB4-ADA6-3CC854D486E8@csr.com>
	<boris.20111129170951@codesynthesis.com>
	<043B89C2-FDBE-4B34-B879-B38FCC210705@csr.com>
	<34C22A81-6459-41CE-A3B8-90AA6085662F@csr.com>
	<781FA5C8-84E5-41BC-A2F3-487B28CE58BA@csr.com>
Message-ID: <boris.20111201151148@codesynthesis.com>

Hi Eric,

Eric Broadbent <eric.broadbent@csr.com> writes:

> And finally, to close the topic: removing validation allows the unexpected 
> attribute to pass without complaint.

Thank for sharing your findings. Just to explain why other methods that
you tried didn't work: Office schemas seems to use what I would call an
"out-of-schema extension". That is, it is an extension that is not
defined in the schemas that they provide and, as a result, their
documents cannot be validated against these schemas (because of these
extra attributes they will be considered invalid).

Boris

From eric.broadbent at csr.com  Mon Dec  5 00:14:38 2011
From: eric.broadbent at csr.com (Eric Broadbent)
Date: Mon Dec  5 00:14:47 2011
Subject: [xsde-users] Type Maps & generated code results
Message-ID: <7BB468D5-EE19-4A3C-98DE-22F55C899C84@csr.com>

I have two different sets of code generated with the same schemas and same basic commands, but one uses a type map file along with the --type-map command, and the other doesn't.  When I compare the generated code, there are no diffs, and the return type from the "post_<type>()" method is still void.

I know that XSDe is at least scanning my type map file because I first had normal C-style comments in there and I got error messages.

I am also using the "--namespace-map" option, and am supplying the same namespace mapping in the map file.
For example, this is in library.map in the .../examples/cxx/parser/library/library.map

  namespace http://www.codesynthesis.com/library library

so as far as I can tell the command line used to generate the parser-code should have also included "--namespace-map http://www.codesynthesis.com/library=library"
This is the convention that I'm using in my map file.

I see that in the examples (library.map and library-pimpl.cxx), the generated code has lines comments indicating where one needs to fill in code to build the object to return in the post_<type>() method:

    // TODO
    //
    // return ... ;

However I don't see any lines like this in the code I'm generating, so I must be doing something wrong.

Given a correct command invocation and a properly formed type map, is there anything else besides the "--type-map" option that we need to do to get the parser to generate the code to use our schema-to-C mappings?
If not, how should I go about debugging this?  I thought that perhaps putting some garbage mappings in the map file would help to illuminate the problem, but they were consumed without any indication of a problem.

Thanks for any advice,

-Eric B.




Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

From boris at codesynthesis.com  Mon Dec  5 12:01:13 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Dec  5 12:10:13 2011
Subject: [xsde-users] Type Maps & generated code results
In-Reply-To: <7BB468D5-EE19-4A3C-98DE-22F55C899C84@csr.com>
References: <7BB468D5-EE19-4A3C-98DE-22F55C899C84@csr.com>
Message-ID: <boris.20111205185628@codesynthesis.com>

Hi Eric,

For a detailed description of the type map file format as well
as examples, please see Chapter 4, "Type Maps" in the Embedded
C++/Parser Mapping Getting Started Guide:

http://codesynthesis.com/projects/xsde/documentation/cxx/parser/guide/#4

As a general rule, the namespace name after the 'namespace' keyword
should be exactly as in the targetNamespace attribute of your schema.
Also make sure that the type name is exactly as in the schema.

If none of this helps, please send a small test case (schema + map
file) that reproduces the problem.

Boris

From eric.broadbent at csr.com  Mon Dec  5 12:09:53 2011
From: eric.broadbent at csr.com (Eric Broadbent)
Date: Mon Dec  5 12:10:29 2011
Subject: [xsde-users] Re: Type Maps & generated code results
In-Reply-To: <7BB468D5-EE19-4A3C-98DE-22F55C899C84@csr.com>
References: <7BB468D5-EE19-4A3C-98DE-22F55C899C84@csr.com>
Message-ID: <0860BC91-6440-45A2-9076-98BBF88FBD4F@csr.com>

I decided to try making a change to the library.map in the examples, and regenerate the skeleton and implementation code to see whether and how it reflects the new mapping.

The file library.map was changed to look like this:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
namespace http://www.codesynthesis.com/library library
{
  include "library.hxx";

  isbn    isbn_C_struct* isbn_C_struct;
}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This allows for a simple search on "C_struct" to tell where the mapping is activated.
Accordingly, I changed the operative part of the library.hxx file to look like this:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
namespace library
{
  //
  //
  typedef unsigned int isbn_C_struct;

}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I removed all the other .cxx and .hxx files - made some makefile changes (to get the driver to be rebuilt), and regenerated all the code.
I don't find any instances of "isbn_C_struct" in the generated code - which otherwise is compiled/linked/run fine and operates normally - but it doesn't allow the access to parsed schema elements that --type-map is supposed to support.

I'm at a loss to know what to do to get the --type-map option to work.
Any help is greatly appreciated.  I can send the three files I changed if that helps:
	library.map
	library.hxx
	makefile

Thanks.
-Eric B.

On Dec 5, 2011, at 12:14 AM, Eric Broadbent wrote:

> I have two different sets of code generated with the same schemas and same basic commands, but one uses a type map file along with the --type-map command, and the other doesn't.  When I compare the generated code, there are no diffs, and the return type from the "post_<type>()" method is still void.
> 
> I know that XSDe is at least scanning my type map file because I first had normal C-style comments in there and I got error messages.
> 
> I am also using the "--namespace-map" option, and am supplying the same namespace mapping in the map file.
> For example, this is in library.map in the .../examples/cxx/parser/library/library.map
> 
>  namespace http://www.codesynthesis.com/library library
> 
> so as far as I can tell the command line used to generate the parser-code should have also included "--namespace-map http://www.codesynthesis.com/library=library"
> This is the convention that I'm using in my map file.
> 
> I see that in the examples (library.map and library-pimpl.cxx), the generated code has lines comments indicating where one needs to fill in code to build the object to return in the post_<type>() method:
> 
>    // TODO
>    //
>    // return ... ;
> 
> However I don't see any lines like this in the code I'm generating, so I must be doing something wrong.
> 
> Given a correct command invocation and a properly formed type map, is there anything else besides the "--type-map" option that we need to do to get the parser to generate the code to use our schema-to-C mappings?
> If not, how should I go about debugging this?  I thought that perhaps putting some garbage mappings in the map file would help to illuminate the problem, but they were consumed without any indication of a problem.
> 
> Thanks for any advice,
> 
> -Eric B.
> 
> 
> 
> 
> Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
> More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
> 
> 
> 
> To report this email as spam click https://www.mailcontrol.com/sr/k3G6A+!G!X3TndxI!oX7Ulvwl1GqFAPrg!Mws13yRuY6A+OyJ60KZ!P9U7BY3q+!TTBbJCW1sDWbYw94u+b0NQ== .


From boris at codesynthesis.com  Mon Dec  5 12:13:32 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Dec  5 12:22:30 2011
Subject: [xsde-users] Re: Type Maps & generated code results
In-Reply-To: <0860BC91-6440-45A2-9076-98BBF88FBD4F@csr.com>
References: <7BB468D5-EE19-4A3C-98DE-22F55C899C84@csr.com>
	<0860BC91-6440-45A2-9076-98BBF88FBD4F@csr.com>
Message-ID: <boris.20111205191024@codesynthesis.com>

Hi Eric,

Eric Broadbent <eric.broadbent@csr.com> writes:

> I don't find any instances of "isbn_C_struct" in the generated code...

I just made the changes that you have described and I see the 
isbn_C_struct type in the generated library-pskel.?xx files. Can you
send me your library.map file? Also, which platform are you running
the XSD/e compiler on?

Boris

From eric.broadbent at csr.com  Fri Dec  9 14:58:14 2011
From: eric.broadbent at csr.com (Eric Broadbent)
Date: Fri Dec  9 14:58:23 2011
Subject: [xsde-users] cxx-hybrid use with cxx-parser?
In-Reply-To: <boris.20111205191024@codesynthesis.com>
References: <7BB468D5-EE19-4A3C-98DE-22F55C899C84@csr.com>
	<0860BC91-6440-45A2-9076-98BBF88FBD4F@csr.com>
	<boris.20111205191024@codesynthesis.com>
Message-ID: <61757BE7-2A42-4748-B2C1-47825A491B4D@csr.com>

I have a main schema which references several child schemas.
I am trying to build a parser which uses the object model generated by the cxx-hybrid tool, to produce output from XML files.
Starting with the serializer implementation is fine - modifications can be made that to write the output format needed.

Is is possible/reasonable to invoke cxx-parser with the --generate-test-driver option - supplying the root element and schema, and then combine that with the rest of the code generated by cxx-hybrid?

Would one need to plug in all the generated classes to a type-map so the parser knows to make the connections in the generated driver code?

There is no "driver" generated by cxx-hybrid - and all the examples use an existing test shell.
Using the cxx-hybrid, one gets this error using the --generate-test-driver option:
	error: unknown option '--generate-test-driver'

If anyone has encountered the same situation and has some advice, would be very interested to hear what method you used.
Thanks, 
-Eric B.

Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

From eric.broadbent at csr.com  Sat Dec 10 17:37:09 2011
From: eric.broadbent at csr.com (Eric Broadbent)
Date: Sat Dec 10 17:37:14 2011
Subject: [xsde-users] Re: cxx-hybrid use with cxx-parser? (new problem)
In-Reply-To: <61757BE7-2A42-4748-B2C1-47825A491B4D@csr.com>
References: <7BB468D5-EE19-4A3C-98DE-22F55C899C84@csr.com>
	<0860BC91-6440-45A2-9076-98BBF88FBD4F@csr.com>
	<boris.20111205191024@codesynthesis.com>
	<61757BE7-2A42-4748-B2C1-47825A491B4D@csr.com>
Message-ID: <3F139065-4FB5-4E08-8151-DCE152653D91@csr.com>

A more critical problem has arisen that I am now stuck with.
A previous encounter with out-of-schema attributes occurring in the XML data forced me to generate the cxx-parser code with the "--suppress-validation" flag, which allows these attributes to be in the datastream benignly.

After learning that I could use cxx-hybrid to build an object model automatically, I decided to try generating code with that.

However, I encountered this error when generating the code from the schema:
	"error: complex type 'CT_GForce' contains choice compositor"
	"error: parser validation is required to handle this construct"

Is there any way to deal with this?  The runtime error forced validation off - whereas the code-generation wants validation on.
The thing that is curious is that validation could be suppressed when generating the code using cxx-parser, but cxx-hybrid requires it - for the same schema elements.

Thanks for any advice.

-Eric B.



On Dec 9, 2011, at 2:58 PM, Eric Broadbent wrote:

> I have a main schema which references several child schemas.
> I am trying to build a parser which uses the object model generated by the cxx-hybrid tool, to produce output from XML files.
> Starting with the serializer implementation is fine - modifications can be made that to write the output format needed.
> 
> Is is possible/reasonable to invoke cxx-parser with the --generate-test-driver option - supplying the root element and schema, and then combine that with the rest of the code generated by cxx-hybrid?
> 
> Would one need to plug in all the generated classes to a type-map so the parser knows to make the connections in the generated driver code?
> 
> There is no "driver" generated by cxx-hybrid - and all the examples use an existing test shell.
> Using the cxx-hybrid, one gets this error using the --generate-test-driver option:
> 	error: unknown option '--generate-test-driver'
> 
> If anyone has encountered the same situation and has some advice, would be very interested to hear what method you used.
> Thanks, 
> -Eric B.
> 
> Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
> More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
> 
> 
> 
> To report this email as spam click https://www.mailcontrol.com/sr/jcZIwo0RHwXTndxI!oX7UqcUCtlg0TD8CTQMQi!GhQowm+gIXlZFPto0MI5lKVzV3y0Wgd5FmiD02A3zwbO5JA== .


From boris at codesynthesis.com  Mon Dec 12 09:15:36 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Dec 12 09:14:28 2011
Subject: [xsde-users] cxx-hybrid use with cxx-parser?
In-Reply-To: <61757BE7-2A42-4748-B2C1-47825A491B4D@csr.com>
References: <7BB468D5-EE19-4A3C-98DE-22F55C899C84@csr.com>
	<0860BC91-6440-45A2-9076-98BBF88FBD4F@csr.com>
	<boris.20111205191024@codesynthesis.com>
	<61757BE7-2A42-4748-B2C1-47825A491B4D@csr.com>
Message-ID: <boris.20111212161044@codesynthesis.com>

Hi Eric,

C++/Hybrid uses C++/Parser underneath. In fact, when you run the
XSD/e compiler with the cxx-hybrid command and --generate-parser
option, the compiler will also generate parser skeletons. Note,
however, that these skeletons were generated using a custom type
map file, one that was automatically produced by C++/Hybrid and
which corresponds to the generated object model.

I think this should then answer your question. Specifically, no, it
is not possible to generate the parser skeletons using cxx-parser
command separately and then use the result with C++/Hybrid. I also
don't see why anyone would want to.

Boris

From boris at codesynthesis.com  Mon Dec 12 09:37:11 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Mon Dec 12 09:36:03 2011
Subject: [xsde-users] Re: How to parse invalid XML when C++/Hybrid requires
	validation
In-Reply-To: <3F139065-4FB5-4E08-8151-DCE152653D91@csr.com>
References: <7BB468D5-EE19-4A3C-98DE-22F55C899C84@csr.com>
	<0860BC91-6440-45A2-9076-98BBF88FBD4F@csr.com>
	<boris.20111205191024@codesynthesis.com>
	<61757BE7-2A42-4748-B2C1-47825A491B4D@csr.com>
	<3F139065-4FB5-4E08-8151-DCE152653D91@csr.com>
Message-ID: <boris.20111212162005@codesynthesis.com>

Hi Eric,

In the future please use a new, descriptive subject for a new question,
instead of replying to an old thread. For more information, see Posting
Guidelines:

http://codesynthesis.com/support/posting-guidelines.xhtml

Eric Broadbent <eric.broadbent@csr.com> writes:

> However, I encountered this error when generating the code from the schema:
> 	"error: complex type 'CT_GForce' contains choice compositor"
> 	"error: parser validation is required to handle this construct"
> 
> Is there any way to deal with this?  The runtime error forced validation 
> off - whereas the code-generation wants validation on.

As the error suggests, C++/Hybrid needs validation if a schema contains
choice compositors. The reason for this is that in XML Schema to associate
content to choice arms one has to do full-blown validation. Because the
C++/Hybrid mapping needs this association, it requires validation if a
schema contains choice compositors.

IMO, the problem here is the invalid XML (per the schema) that you are 
trying to parse and the solution is to try and transform it to something
valid. I remembers you mentioned that the "extension" attributes/elements
can appear pretty much anywhere in the document. This means that what we
need is some kind of a global filtering mechanism. One way to do this
would be to intercept raw SAX callbacks (start element, end element,
characters) and filter the "extension" content at that level. You can
do this by inheriting from xml_schema::document_pimpl and providing
your own Expat callbacks after the call to parse_begin(). You will
also need to call the original callbacks if the content should be
parsed. See source code in libxsde/xsde/cxx/parser/expat/document.?xx
for details.

Boris

From eric.broadbent at csr.com  Mon Dec 12 14:19:03 2011
From: eric.broadbent at csr.com (Eric Broadbent)
Date: Mon Dec 12 14:19:11 2011
Subject: [xsde-users] Re: How to parse invalid XML when C++/Hybrid requires
	validation
In-Reply-To: <boris.20111212162005@codesynthesis.com>
References: <7BB468D5-EE19-4A3C-98DE-22F55C899C84@csr.com>
	<0860BC91-6440-45A2-9076-98BBF88FBD4F@csr.com>
	<boris.20111205191024@codesynthesis.com>
	<61757BE7-2A42-4748-B2C1-47825A491B4D@csr.com>
	<3F139065-4FB5-4E08-8151-DCE152653D91@csr.com>
	<boris.20111212162005@codesynthesis.com>
Message-ID: <B82D727E-1FD0-4ADB-A102-3A41E0E74555@csr.com>

Thanks Boris for your advice here, and sorry for the non-conforming post.
I will try content filtering as you suggest.  As it is I have no control over the schema so will have to deal with the rogue attributes.
Hopefully the subclass/override will end up being trivial, but if you or anyone else on the list knows of other examples of this kind of filtering, a link would certainly be helpful.
If I end up creating a successful filter I'd be happy to share how it was done.

-Eric

On Dec 12, 2011, at 9:37 AM, Boris Kolpackov wrote:

> Hi Eric,
> 
> In the future please use a new, descriptive subject for a new question,
> instead of replying to an old thread. For more information, see Posting
> Guidelines:
> 
> http://codesynthesis.com/support/posting-guidelines.xhtml
> 
> Eric Broadbent <eric.broadbent@csr.com> writes:
> 
>> However, I encountered this error when generating the code from the schema:
>> 	"error: complex type 'CT_GForce' contains choice compositor"
>> 	"error: parser validation is required to handle this construct"
>> 
>> Is there any way to deal with this?  The runtime error forced validation 
>> off - whereas the code-generation wants validation on.
> 
> As the error suggests, C++/Hybrid needs validation if a schema contains
> choice compositors. The reason for this is that in XML Schema to associate
> content to choice arms one has to do full-blown validation. Because the
> C++/Hybrid mapping needs this association, it requires validation if a
> schema contains choice compositors.
> 
> IMO, the problem here is the invalid XML (per the schema) that you are 
> trying to parse and the solution is to try and transform it to something
> valid. I remembers you mentioned that the "extension" attributes/elements
> can appear pretty much anywhere in the document. This means that what we
> need is some kind of a global filtering mechanism. One way to do this
> would be to intercept raw SAX callbacks (start element, end element,
> characters) and filter the "extension" content at that level. You can
> do this by inheriting from xml_schema::document_pimpl and providing
> your own Expat callbacks after the call to parse_begin(). You will
> also need to call the original callbacks if the content should be
> parsed. See source code in libxsde/xsde/cxx/parser/expat/document.?xx
> for details.
> 
> Boris
> 
> 
> To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== .



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

From frederic.heitzmann at gmail.com  Mon Dec 12 17:06:58 2011
From: frederic.heitzmann at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Heitzmann?=)
Date: Tue Dec 13 01:10:20 2011
Subject: [xsde-users] missing deployment procedure ?
Message-ID: <4EE67B02.2010505@gmail.com>

Hi all,

xsde looks really helpful but I find it rather hard to install it properly.
=> Is there any "make install" rules or equivalent ?
I looked across the makefiles and found none.
=> At least, is there a list of the header files which should be copied 
into usr/local/include ?
Looking at the huge work that was done with xsde, this is a pity that 
this final step is missing ...

Any idea, link, or advice is welcome.

--
Fred

From boris at codesynthesis.com  Tue Dec 13 08:11:05 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Tue Dec 13 08:09:49 2011
Subject: [xsde-users] missing deployment procedure ?
In-Reply-To: <4EE67B02.2010505@gmail.com>
References: <4EE67B02.2010505@gmail.com>
Message-ID: <boris.20111213150546@codesynthesis.com>

Hi Fr?d?ric,

Fr?d?ric Heitzmann <frederic.heitzmann@gmail.com> writes:

> => Is there any "make install" rules or equivalent ?
> I looked across the makefiles and found none.
> => At least, is there a list of the header files which should be copied  
> into usr/local/include ?

I have added the install target to the 'dist' makefiles (i.e., makefiles
found in the packages containing pre-built XSD/e compiler with sources
for libxsde and examples). This will appear in the next release of XSD/e
but you can also add this capability to XSD/e 3.2.0 using this package:

http://www.codesynthesis.com/~boris/tmp/xsde/xsde-3.2.0-install.tar.gz

Simply override the files in the vanilla 3.2.0 distribution with the
ones in this archive.

Quoting from the updated INSTALL file:

"
You can also install the XSD/e compiler as well as the XSD/e
runtime headers and library by running 'make install'. By
default the installation directory is /usr/local but this
can be changed with the 'install_*' command line variables.
By default they have the following values:

install_prefix  = /usr/local
install_bin     = install_prefix/bin
install_man     = install_prefix/man
install_lib     = install_prefix/lib
install_include = install_prefix/include

For example, to install XSD/e into /usr with the XSD/e runtime
library in /usr/lib64, you can use the following command line:

make install install_prefix=/usr install_lib=/usr/lib64
"

Let me know if you run into any problems.

Boris

From eric.broadbent at csr.com  Thu Dec 15 14:51:39 2011
From: eric.broadbent at csr.com (Eric Broadbent)
Date: Thu Dec 15 14:51:47 2011
Subject: [xsde-users] root element subset within a large schema/namespace
Message-ID: <490FB0F2-DE18-4B61-8630-1A43D8A0CCBC@csr.com>

The element (and children) that I am currently attempting to parse is part of a comprehensive schema which also references about a dozen other schemas.
The element that I need to generate an object model for only refers to a couple of these other schemas, so ideally I would like not to have to generate code for all the possible elements in the rest of the namespace that I don't care about.

All of the examples that I've found deal with simple XML schemas and documents - and I can't tell whether what I would like to do is possible.
In a previous attempt, I was able to at least not invoke all the generated pskel/pimpl objects in the schema namespace by calling only the specific parser settor method for my root element.
I.e. in the generated code - instead of calling the "parsers" method to assign all parsers at once - I called just the method needed for my element of interest.
(in the "driver" code main)
- - - - - - - - - - - - - - - - - - - - -
  try
  {
    // Instantiate individual parsers.
    //
    CT_Document_pimpl CT_Document_p;
    CT_DocEl1_pimpl CT_DocEl1_p;
    CT_DocEl2_pimpl CT_DocEl2_p;
    ..
    CT_MyRootEl_pimpl CT_MyRootEl_p;
    ..
    ... many hundreds more of elements here - most not needed ...
    ...
    //
    // Connect the parsers together.
    //
    ...
#ifdef  ORIGINAL_CODE
    CT_Document_p.parsers (
                        ...
                        CT_DocEl1_p,
                        CT_DocEl2_p,
                        ...
                        CT_MyRootEl_p,
                        ... );

#else /* my customization */

    CT_DocRoot.targetelement_parser (CT_MyRootEl_p);

#endif /* ORIGINAL_CODE  or my customization */
    ...    
- - - - - - - - - - - - - - - - - - - - - - - - - 
Now that I'm using C++/Hybrid and the serializer code, the entire executable is quite large (40MB) and contains a lot of code that I don't really need, but I don't know exactly how to exclude all the unnecessary stuff.  If I provide the main schema and it's dependent schemas as required, XSD/e will generate code for all the contained elements - even if I use the "--root-element" option.

I suppose one way to deal with this is to generate my own copy of the schema which has only the target element/children that I want, and then filter the XML documents on input so that the only piece of the input stream that's given to the document_pimpl is the piece of interest.

Are there other ways of dealing with this that don't require schema-trimming?
Is there something in the examples that I just haven't looked for hard enough?

Thanks,

-Eric B.
Zoran/CSR



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

From boris at codesynthesis.com  Fri Dec 16 08:50:30 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Dec 16 08:48:54 2011
Subject: [xsde-users] root element subset within a large schema/namespace
In-Reply-To: <490FB0F2-DE18-4B61-8630-1A43D8A0CCBC@csr.com>
References: <490FB0F2-DE18-4B61-8630-1A43D8A0CCBC@csr.com>
Message-ID: <boris.20111216153156@codesynthesis.com>

Hi Eric,

Eric Broadbent <eric.broadbent@csr.com> writes:

> Now that I'm using C++/Hybrid and the serializer code, the entire 
> executable is quite large (40MB) and contains a lot of code that
> I don't really need, but I don't know exactly how to exclude all
> the unnecessary stuff.  If I provide the main schema and it's 
> dependent schemas as required, XSD/e will generate code for all 
> the contained elements - even if I use the "--root-element" option.
> 
> I suppose one way to deal with this is to generate my own copy of
> the schema which has only the target element/children that I want,
> and then filter the XML documents on input so that the only piece
> of the input stream that's given to the document_pimpl is the piece
> of interest.

Yes, that's probably the most precise method, though may require
quite a bit of manual work from your part.


> Are there other ways of dealing with this that don't require 
> schema-trimming?

You can try the following approach:

1. Compile your schema with the --file-per-type option. This will
   result in hundreds (if not thousands) of source files, one for
   each schema type.

2. Compile them and put them into a static library (.a on Linux/UNIX,
   .lib on Windows). The compilation time will probably be atrocious,
   much, much longer than without the --file-per-type option. If you
   can, try to use the -j GNU make option to compile in parallel.

3. You cannot use the generated aggregates with this approach. Instead,
   you will need to assemble the parser yourself, as you did for the
   C++/Parser mapping, and not setting the parsers in which you are
   not interested in. One thing that you can do to help with this
   task is to generate aggregates for top-level types in which you
   are interested in instead of the root element (use the --root-type
   option). For example, if you have something like this:

   <xsd:complexType name="root_t">
     <xsd:sequence>
       <xsd:element name="foo" type="foo_t"/>
       <xsd:element name="bar" type="bar_t"/>
       <xsd:element name="baz" type="baz_t"/>
     </xsd:sequence>
   </xsd:complexType>

   <xsd:element name="root" type="root_t"/>
   
   And you are only interested in the foo and baz elements, then instead
   of generating an aggregate for the root element, you generate aggregates
   for foo_t and baz_t, and then assemble the root_t parser using these
   two aggregates.

4. Link your application using the static library created on step 2. The
   idea here is to take advantage of the static linker behavior, which
   ignores object files in the archive that don't satisfy any symbols
   in the resulting executable. While you will still end up with all
   the pskel/sskel files in the executable, the pimpl/simpl files for
   unused content will be ignored. When comparing executable sizes
   between the two approaches, it is a good idea to compile everything
   with optimization.

Boris

From Eric.Broadbent at csr.com  Fri Dec 16 18:11:22 2011
From: Eric.Broadbent at csr.com (Eric Broadbent)
Date: Fri Dec 16 18:11:37 2011
Subject: [xsde-users] root element subset within a large	schema/namespace
In-Reply-To: <boris.20111216153156@codesynthesis.com>
References: <490FB0F2-DE18-4B61-8630-1A43D8A0CCBC@csr.com>
	<boris.20111216153156@codesynthesis.com>
Message-ID: <184B513B-DCFE-473E-8161-E6B963804E5E@csr.com>

Hi Boris,
I appreciate your helpful reply.
Compiling the generated code will reveal the dependencies on a reduced schema (i.e. when other schemas are required there will be an include), so I am going to try editing the schema first
It's not simple, but I believe it's less work than the single-file-per-element method.
Thanks again for your help with this.

-Eric

On Dec 16, 2011, at 8:50 AM, Boris Kolpackov wrote:

> Hi Eric,
> 
> Eric Broadbent <eric.broadbent@csr.com> writes:
> 
>> Now that I'm using C++/Hybrid and the serializer code, the entire 
>> executable is quite large (40MB) and contains a lot of code that
>> I don't really need, but I don't know exactly how to exclude all
>> the unnecessary stuff.  If I provide the main schema and it's 
>> dependent schemas as required, XSD/e will generate code for all 
>> the contained elements - even if I use the "--root-element" option.
>> 
>> I suppose one way to deal with this is to generate my own copy of
>> the schema which has only the target element/children that I want,
>> and then filter the XML documents on input so that the only piece
>> of the input stream that's given to the document_pimpl is the piece
>> of interest.
> 
> Yes, that's probably the most precise method, though may require
> quite a bit of manual work from your part.
> 
> 
>> Are there other ways of dealing with this that don't require 
>> schema-trimming?
> 
> You can try the following approach:
> 
> 1. Compile your schema with the --file-per-type option. This will
>   result in hundreds (if not thousands) of source files, one for
>   each schema type.
> 
> 2. Compile them and put them into a static library (.a on Linux/UNIX,
>   .lib on Windows). The compilation time will probably be atrocious,
>   much, much longer than without the --file-per-type option. If you
>   can, try to use the -j GNU make option to compile in parallel.
> 
> 3. You cannot use the generated aggregates with this approach. Instead,
>   you will need to assemble the parser yourself, as you did for the
>   C++/Parser mapping, and not setting the parsers in which you are
>   not interested in. One thing that you can do to help with this
>   task is to generate aggregates for top-level types in which you
>   are interested in instead of the root element (use the --root-type
>   option). For example, if you have something like this:
> 
>   <xsd:complexType name="root_t">
>     <xsd:sequence>
>       <xsd:element name="foo" type="foo_t"/>
>       <xsd:element name="bar" type="bar_t"/>
>       <xsd:element name="baz" type="baz_t"/>
>     </xsd:sequence>
>   </xsd:complexType>
> 
>   <xsd:element name="root" type="root_t"/>
> 
>   And you are only interested in the foo and baz elements, then instead
>   of generating an aggregate for the root element, you generate aggregates
>   for foo_t and baz_t, and then assemble the root_t parser using these
>   two aggregates.
> 
> 4. Link your application using the static library created on step 2. The
>   idea here is to take advantage of the static linker behavior, which
>   ignores object files in the archive that don't satisfy any symbols
>   in the resulting executable. While you will still end up with all
>   the pskel/sskel files in the executable, the pimpl/simpl files for
>   unused content will be ignored. When comparing executable sizes
>   between the two approaches, it is a good idea to compile everything
>   with optimization.
> 
> Boris
> 
> 
> To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== .



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

From Eric.Broadbent at csr.com  Tue Dec 20 11:27:58 2011
From: Eric.Broadbent at csr.com (Eric Broadbent)
Date: Tue Dec 20 11:29:19 2011
Subject: [xsde-users] serializer callback overrides sometimes present,
	sometimes not
Message-ID: <2269DF76-8BBD-4A77-AF04-45ABAC978035@csr.com>

I am using the C++/Hybrid and customizing the _serialize_content() callbacks in my _simpl classes.

What I've found is that not all elements in the _sskel classes have a  _serialize_content() method, and also that there is not a 1-1 mapping to the _simpl classes that have _serialize_content() methods.

In other words, I've found _simpl classes that override _serialize_content(), but the _sskel superclass that they inherit from does not expose a virtual _serialize_content() method, and the opposite case also occurs.

Is there a particular set of element attributes or contents which will determine whether C++/Hybrid with the --generate-serializer option will emit vs. omit _serialize_content() methods in the _sskel and _simpl classes?

Thanks,

-Eric B.
Zoran/CSR

Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

From Eric.Broadbent at csr.com  Tue Dec 20 12:00:40 2011
From: Eric.Broadbent at csr.com (Eric Broadbent)
Date: Tue Dec 20 12:00:53 2011
Subject: [xsde-users] serializer callback overrides sometimes present,
	sometimes not
In-Reply-To: <2269DF76-8BBD-4A77-AF04-45ABAC978035@csr.com>
References: <2269DF76-8BBD-4A77-AF04-45ABAC978035@csr.com>
Message-ID: <7A590765-326F-41AC-9C66-0B89F1FF580B@csr.com>

An attempt to answer my own question:

It appears that the division of labor between _sskel and _simpl is that _sskel code contains _serialize_content() methods for the classes associated with ComplexType elements, and the _simpl code contains _serialize_content() methods for the SimpleType classes/elements.

If this is correct, I'm all set - and sorry to bother anyone.

-Eric B.
Zoran/CSR

On Dec 20, 2011, at 11:27 AM, Eric Broadbent wrote:

> I am using the C++/Hybrid and customizing the _serialize_content() callbacks in my _simpl classes.
> 
> What I've found is that not all elements in the _sskel classes have a  _serialize_content() method, and also that there is not a 1-1 mapping to the _simpl classes that have _serialize_content() methods.
> 
> In other words, I've found _simpl classes that override _serialize_content(), but the _sskel superclass that they inherit from does not expose a virtual _serialize_content() method, and the opposite case also occurs.
> 
> Is there a particular set of element attributes or contents which will determine whether C++/Hybrid with the --generate-serializer option will emit vs. omit _serialize_content() methods in the _sskel and _simpl classes?
> 
> Thanks,
> 
> -Eric B.
> Zoran/CSR
> 
> Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
> More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
> 
> 
> 
> To report this email as spam click https://www.mailcontrol.com/sr/UmAbQpk3OjXTndxI!oX7UpJAdpTSMUBq5CV24yS5urJa!beTmDCbg47TzIuxB2hIGRTWn85OBahhjvXYAQ53ow== .


From Jonathan.Haws at sdl.usu.edu  Wed Dec 21 19:16:32 2011
From: Jonathan.Haws at sdl.usu.edu (Jonathan Haws)
Date: Thu Dec 22 01:46:08 2011
Subject: [xsde-users] xs:any and xs:anyAttribute
Message-ID: <DDDB9E6645DE24488B8485B41A051F471322B5A3@Mercury.usurf.usu.edu>

I am getting started on a project where I have been provided with a few XML schemas in *.xsd files and am trying to figure out how I can get them all into a single parser.  These are CoT schemas, so I cannot change them.  I am also a noob when it comes to XML, but have a basic understanding of it.

Ideally what I would like to end up with is something similar to the Hello example where I parse whatever is coming in and serialize my data in the same way on the way out (I will only be supporting a single sub-schema during serialization).

Basically, this is what I have:

<event>
  <point/>
  <detail>
    <!-- Varied schema(s) found in separate file is added here -->
  </detail>
</event>

Here is the schema for detail:

<xs:element name="detail">
    <xs:annotation>
        <xs:documentation>
            format = XML schema defined outside of this document
        </xs:documentation>
    </xs:annotation>
    <xs:complexType>
        <xs:sequence>
            <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:anyAttribute processContents="skip"/>
    </xs:complexType>
</xs:element>

So, I could have something that looks like this in my XML input to the parser:

<event>
  <point/>
  <detail>
    <shape/>
    <color/>
    <track/>
    <link/>
    <contact/>
  </detail>
</event>

Each separate element (shape, color, track, link, contact) each are defined in their own schema (separate XSD files).

Since I can have multiple elements from multiple schemas in the detail element, how can I generate the code for this?  I read the user guide on parser reuse, but did not see how it would do what I need it to do.  Also, the Wiki page on CoT refers to using XSD, but I am working in an embedded system, thus XSD/e is a better fit.

Anyway, is there an example that would show how this can be done?  Or can anyone answer my questions and/or guide me in the right direction?  It would be awesome to be able to support every single XSD file in parsing and serialization transparently.

Thanks!

Jonathan
jhaws@sdl.usu.edu

PS - There is also a schema called Universal Core (or UCore) that I plan to use in the future as well.  It's schemas seem to be fashioned in the same manner as I am describing, so figuring this out now would be great!

Thanks!

From Eric.Broadbent at csr.com  Thu Dec 22 02:04:25 2011
From: Eric.Broadbent at csr.com (Eric Broadbent)
Date: Thu Dec 22 02:05:10 2011
Subject: [xsde-users] xs:any and xs:anyAttribute
In-Reply-To: <DDDB9E6645DE24488B8485B41A051F471322B5A3@Mercury.usurf.usu.edu>
References: <DDDB9E6645DE24488B8485B41A051F471322B5A3@Mercury.usurf.usu.edu>
Message-ID: <3F201A13-F55F-4B1D-9B3A-54162BB9AAB3@csr.com>

I am doing something like this, and have had several trial-and-error runs so far to get it to do what I want, but I'm almost there.  What I've done is to generate the code using separate invocations of XSD/e cxx-hybrid, with the first one working on all the sub-schemas - like this:

-> setenv XSDFLAGS "--generate-parser --generate-serializer  ... "
-> $XSDE cxx-hybrid  $XSDFLAGS \
sub-schema1.xsd  sub-schema2.xsd sub-schema3.xsd ... sub-schemaN.xsd

(Note I am setting other options in XSDFLAGS besides the ones above, but the critical ones are shown)
Then I change the flags to identify the root-element which I want XSD/e to generate an aggregate parser and serializer for, and I provide the main schema only in this invocation:

-> setenv XSDFLAGS "--generate-parser --generate-serializer  --generate-aggregate --root-element timing ... "
-> $XSDE cxx-hybrid  $XSDFLAGS \
main-schema.xsd

Then I compile all the code and link it - except the missing link is that I had to cobble together a "driver" by looking at the other example drivers, because the cxx-hybrid code-generator doesn't support the "--generate-test-driver" option.
It wasn't too hard to do, so if you get stuck with this let me know.

Eric B.
Zoran/CSR

On Dec 21, 2011, at 7:16 PM, Jonathan Haws wrote:

> I am getting started on a project where I have been provided with a few XML schemas in *.xsd files and am trying to figure out how I can get them all into a single parser.  These are CoT schemas, so I cannot change them.  I am also a noob when it comes to XML, but have a basic understanding of it.
> 
> Ideally what I would like to end up with is something similar to the Hello example where I parse whatever is coming in and serialize my data in the same way on the way out (I will only be supporting a single sub-schema during serialization).
> 
> Basically, this is what I have:
> 
> <event>
>  <point/>
>  <detail>
>    <!-- Varied schema(s) found in separate file is added here -->
>  </detail>
> </event>
> 
> Here is the schema for detail:
> 
> <xs:element name="detail">
>    <xs:annotation>
>        <xs:documentation>
>            format = XML schema defined outside of this document
>        </xs:documentation>
>    </xs:annotation>
>    <xs:complexType>
>        <xs:sequence>
>            <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
>        </xs:sequence>
>        <xs:anyAttribute processContents="skip"/>
>    </xs:complexType>
> </xs:element>
> 
> So, I could have something that looks like this in my XML input to the parser:
> 
> <event>
>  <point/>
>  <detail>
>    <shape/>
>    <color/>
>    <track/>
>    <link/>
>    <contact/>
>  </detail>
> </event>
> 
> Each separate element (shape, color, track, link, contact) each are defined in their own schema (separate XSD files).
> 
> Since I can have multiple elements from multiple schemas in the detail element, how can I generate the code for this?  I read the user guide on parser reuse, but did not see how it would do what I need it to do.  Also, the Wiki page on CoT refers to using XSD, but I am working in an embedded system, thus XSD/e is a better fit.
> 
> Anyway, is there an example that would show how this can be done?  Or can anyone answer my questions and/or guide me in the right direction?  It would be awesome to be able to support every single XSD file in parsing and serialization transparently.
> 
> Thanks!
> 
> Jonathan
> jhaws@sdl.usu.edu
> 
> PS - There is also a schema called Universal Core (or UCore) that I plan to use in the future as well.  It's schemas seem to be fashioned in the same manner as I am describing, so figuring this out now would be great!
> 
> Thanks!
> 
> 
> 
> To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== .



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

From boris at codesynthesis.com  Thu Dec 22 07:20:09 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Dec 22 07:17:58 2011
Subject: [xsde-users] xs:any and xs:anyAttribute
In-Reply-To: <DDDB9E6645DE24488B8485B41A051F471322B5A3@Mercury.usurf.usu.edu>
References: <DDDB9E6645DE24488B8485B41A051F471322B5A3@Mercury.usurf.usu.edu>
Message-ID: <boris.20111222141639@codesynthesis.com>

Hi Jonathan,

Jonathan Haws <Jonathan.Haws@sdl.usu.edu> writes:

> Anyway, is there an example that would show how this can be done?

Yes, see the 'wildcard' example. As Eric mentioned in his reply, you
will need to compile each schema separately. Then you will need to
route the widlcard content callbacks to the corresponding parser or
serializer. The 'wildcard' example shows how to do this.

Boris

From Jonathan.Haws at sdl.usu.edu  Fri Dec 23 00:25:51 2011
From: Jonathan.Haws at sdl.usu.edu (Jonathan Haws)
Date: Fri Dec 23 00:25:59 2011
Subject: [xsde-users] xs:any and xs:anyAttribute
In-Reply-To: <boris.20111222141639@codesynthesis.com>
References: <DDDB9E6645DE24488B8485B41A051F471322B5A3@Mercury.usurf.usu.edu>
	<boris.20111222141639@codesynthesis.com>
Message-ID: <DDDB9E6645DE24488B8485B41A051F471322BA34@Mercury.usurf.usu.edu>

Here is a quick question:

In the wildcard examples, how does the driver know that the xs:any is an envelope?  It seems that it is fine with how it is setup now, with envelope being the only option.  But let's say that we have two different envelopes - a square and a rectangle.  How does the driver distinguish that when making the call to _post()?

In my situation, I have a number of possibilities.  And the stuff in <detail> can be any number of things - a <color>, a <shape>, or something else.  Is there an example of that?  Or am I missing something?

Thanks!

Jonathan



-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Thursday, December 22, 2011 05:20
To: Jonathan Haws
Cc: xsde-users@codesynthesis.com
Subject: Re: [xsde-users] xs:any and xs:anyAttribute

Hi Jonathan,

Jonathan Haws <Jonathan.Haws@sdl.usu.edu> writes:

> Anyway, is there an example that would show how this can be done?

Yes, see the 'wildcard' example. As Eric mentioned in his reply, you
will need to compile each schema separately. Then you will need to
route the widlcard content callbacks to the corresponding parser or
serializer. The 'wildcard' example shows how to do this.

Boris

From Jonathan.Haws at sdl.usu.edu  Fri Dec 23 00:36:15 2011
From: Jonathan.Haws at sdl.usu.edu (Jonathan Haws)
Date: Fri Dec 23 00:36:24 2011
Subject: [xsde-users] xs:any and xs:anyAttribute
In-Reply-To: <DDDB9E6645DE24488B8485B41A051F471322BA34@Mercury.usurf.usu.edu>
References: <DDDB9E6645DE24488B8485B41A051F471322B5A3@Mercury.usurf.usu.edu>
	<boris.20111222141639@codesynthesis.com>
	<DDDB9E6645DE24488B8485B41A051F471322BA34@Mercury.usurf.usu.edu>
Message-ID: <DDDB9E6645DE24488B8485B41A051F471322BA5C@Mercury.usurf.usu.edu>

Boris and Eric,

I guess my biggest question lies in how to get the sub-schema parsers tied into the main parser.  The wildcard example is not clear to me on how that is done.  

I have generated code in the following manner:

This command is for the sub-schemas:
# xsde cxx-hybrid --generate-parser --generate-serializer --custom-parser --custom-serializer CoT_contact.xsd CoT__flow-tags.xsd CoT_image.xsd CoT_link.xsd CoT_remarks.xsd CoT_request.xsd CoT_sensor.xsd CoT_shape.xsd CoT_spatial.xsd CoT_track.xsd CoT_uid.xsd

This command is for the top-level schema:
# xsde cxx-hybrid --generate-parser --generate-serializer --generate-aggregate --custom-data contact --custom-data link --custom-data image --custom-data _flow-tags --custom-data remarks --custom-data request --custom-data sensor --custom-data shape --custom-data spatial --custom-data track --custom-data uid --root-element detail Event-PUBLIC.xsd

Again, a valid XML has this structure:

<event>
  <point/>
  <detail>
    <!-- Varied schema(s) found in separate file is added here -->
  </detail>
</event>

I don't know if specifying detail as the root-element is correct?  The generated detail parser skeleton contains routines such as _start_any_element and _end_any_element, but I could not find any references to how I tie in all the lower level parsers.

Is this a correct statement:  when the top-level parser gets to the <detail> element, it recognizes that what is in <detail> are xs:any fields.  At this point it hands parsing off to the _start_any_element routine.  When a valid XML tag is found, it pulls the name of that tag and calls the appropriate parser for that tag, then moves onto the next one.  Is that correct?  Will XSD/e generate the function table for that if I provide it the correct options?

Again, what I am looking for is a way to setup a makefile that will generate and tie together all the parsing and serialization code.  Then all I need to do is write the driver.

Thanks!

Jonathan


-----Original Message-----
From: xsde-users-bounces@codesynthesis.com [mailto:xsde-users-bounces@codesynthesis.com] On Behalf Of Jonathan Haws
Sent: Thursday, December 22, 2011 22:26
To: Boris Kolpackov
Cc: xsde-users@codesynthesis.com
Subject: RE: [xsde-users] xs:any and xs:anyAttribute

Here is a quick question:

In the wildcard examples, how does the driver know that the xs:any is an envelope?  It seems that it is fine with how it is setup now, with envelope being the only option.  But let's say that we have two different envelopes - a square and a rectangle.  How does the driver distinguish that when making the call to _post()?

In my situation, I have a number of possibilities.  And the stuff in <detail> can be any number of things - a <color>, a <shape>, or something else.  Is there an example of that?  Or am I missing something?

Thanks!

Jonathan



-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com]
Sent: Thursday, December 22, 2011 05:20
To: Jonathan Haws
Cc: xsde-users@codesynthesis.com
Subject: Re: [xsde-users] xs:any and xs:anyAttribute

Hi Jonathan,

Jonathan Haws <Jonathan.Haws@sdl.usu.edu> writes:

> Anyway, is there an example that would show how this can be done?

Yes, see the 'wildcard' example. As Eric mentioned in his reply, you will need to compile each schema separately. Then you will need to route the widlcard content callbacks to the corresponding parser or serializer. The 'wildcard' example shows how to do this.

Boris


From Eric.Broadbent at csr.com  Fri Dec 23 02:11:21 2011
From: Eric.Broadbent at csr.com (Eric Broadbent)
Date: Fri Dec 23 02:12:41 2011
Subject: [xsde-users] xs:any and xs:anyAttribute
In-Reply-To: <DDDB9E6645DE24488B8485B41A051F471322BA5C@Mercury.usurf.usu.edu>
References: <DDDB9E6645DE24488B8485B41A051F471322B5A3@Mercury.usurf.usu.edu>
	<boris.20111222141639@codesynthesis.com>
	<DDDB9E6645DE24488B8485B41A051F471322BA34@Mercury.usurf.usu.edu>
	<DDDB9E6645DE24488B8485B41A051F471322BA5C@Mercury.usurf.usu.edu>
Message-ID: <7EF07471-5B33-4D1D-8E00-3DC5F68C649D@csr.com>

I am not using wildcard or relying on the _any_element handlers, so I don't have the answers you need.

What I have discovered - for content not matching the "any" wildcard, is that elements are ignored unless there is a parser for them, and all of their children will be ignored too.

At least in the non-"any" scenario, if you provide a "root" parser for "detail" without also providing a parser for "event", then your detail parser will not get invoked.  As may be seen below, this may not be the case when "xsd:any" is involved, so I can't answer the question definitively.

The code that controls this is in xsde::cxx::parser::expat::document_pimpl::start_element - which is the main expat element callback:
(a snippet of start_element)
- - - - - - - - - - - - - - - - - - - - - - - - - - -
            ...
            // Dispatch.
            //
            if (cur.depth_ > 0)
            {
              if (cur.any_)
              {
                // Handling content matched by a wildcard.
                //
                cur.depth_++;

#ifdef XSDE_POLYMORPHIC
                cur.parser_->_start_any_element (ns, name, type);
#else
                cur.parser_->_start_any_element (ns, name);
#endif
              }
              else
              {
                // Ignoring content for which there is no parser.
                //
                cur.depth_++;
              }
            }
            else if (cur.parser_)
            {
              // The "normal" case: call _start_element which will
              // call pre() and set the nested parser. We then call
              // _pre_impl on that (which will push the new parser).
              //
              ...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Note that "cur.any_" controls whether elements are ignored - when "cur.depth" is greater than zero.
The "cur.depth" counter will be zero at the top level, and gets incremented when an element is skipped.
I've watched this happen because in my case I want to parse only some of the top-level element's children and ignore others - so I set things up with my root elements as the child elements of interest - but the parsers for them are never getting called.

The situation for the "any" case is different - as you can see from the code.  If the element matches "xsd:any" It looks like your parser may still get called via _start_any_element - even if you don't provide top-level parsers.
As to how you wire up your root elements from there - I haven't had time to look further but perhaps the wildcard example illustrates this.

BTW - if you change the CFLAGS and CXXFLAGS in the top-level config.make so that they don't contain optimization and also include the "-g" option, you can compile the library with symbols - and then you can step through routines like xsde::cxx::parser::expat::document_pimpl::start_element(...), and _start_any_element(...).

Boris will of course have much more valuable things to say, so I apologize if *any* of this is misleading (no pun intended).

-Eric B.
Zoran/CSR


On Dec 23, 2011, at 12:36 AM, Jonathan Haws wrote:

> Boris and Eric,
> 
> I guess my biggest question lies in how to get the sub-schema parsers tied into the main parser.  The wildcard example is not clear to me on how that is done.  
> 
> I have generated code in the following manner:
> 
> This command is for the sub-schemas:
> # xsde cxx-hybrid --generate-parser --generate-serializer --custom-parser --custom-serializer CoT_contact.xsd CoT__flow-tags.xsd CoT_image.xsd CoT_link.xsd CoT_remarks.xsd CoT_request.xsd CoT_sensor.xsd CoT_shape.xsd CoT_spatial.xsd CoT_track.xsd CoT_uid.xsd
> 
> This command is for the top-level schema:
> # xsde cxx-hybrid --generate-parser --generate-serializer --generate-aggregate --custom-data contact --custom-data link --custom-data image --custom-data _flow-tags --custom-data remarks --custom-data request --custom-data sensor --custom-data shape --custom-data spatial --custom-data track --custom-data uid --root-element detail Event-PUBLIC.xsd
> 
> Again, a valid XML has this structure:
> 
> <event>
>  <point/>
>  <detail>
>    <!-- Varied schema(s) found in separate file is added here -->
>  </detail>
> </event>
> 
> I don't know if specifying detail as the root-element is correct?  The generated detail parser skeleton contains routines such as _start_any_element and _end_any_element, but I could not find any references to how I tie in all the lower level parsers.
> 
> Is this a correct statement:  when the top-level parser gets to the <detail> element, it recognizes that what is in <detail> are xs:any fields.  At this point it hands parsing off to the _start_any_element routine.  When a valid XML tag is found, it pulls the name of that tag and calls the appropriate parser for that tag, then moves onto the next one.  Is that correct?  Will XSD/e generate the function table for that if I provide it the correct options?
> 
> Again, what I am looking for is a way to setup a makefile that will generate and tie together all the parsing and serialization code.  Then all I need to do is write the driver.
> 
> Thanks!
> 
> Jonathan
> 
> 
> -----Original Message-----
> From: xsde-users-bounces@codesynthesis.com [mailto:xsde-users-bounces@codesynthesis.com] On Behalf Of Jonathan Haws
> Sent: Thursday, December 22, 2011 22:26
> To: Boris Kolpackov
> Cc: xsde-users@codesynthesis.com
> Subject: RE: [xsde-users] xs:any and xs:anyAttribute
> 
> Here is a quick question:
> 
> In the wildcard examples, how does the driver know that the xs:any is an envelope?  It seems that it is fine with how it is setup now, with envelope being the only option.  But let's say that we have two different envelopes - a square and a rectangle.  How does the driver distinguish that when making the call to _post()?
> 
> In my situation, I have a number of possibilities.  And the stuff in <detail> can be any number of things - a <color>, a <shape>, or something else.  Is there an example of that?  Or am I missing something?
> 
> Thanks!
> 
> Jonathan
> 
> 
> 
> -----Original Message-----
> From: Boris Kolpackov [mailto:boris@codesynthesis.com]
> Sent: Thursday, December 22, 2011 05:20
> To: Jonathan Haws
> Cc: xsde-users@codesynthesis.com
> Subject: Re: [xsde-users] xs:any and xs:anyAttribute
> 
> Hi Jonathan,
> 
> Jonathan Haws <Jonathan.Haws@sdl.usu.edu> writes:
> 
>> Anyway, is there an example that would show how this can be done?
> 
> Yes, see the 'wildcard' example. As Eric mentioned in his reply, you will need to compile each schema separately. Then you will need to route the widlcard content callbacks to the corresponding parser or serializer. The 'wildcard' example shows how to do this.
> 
> Boris
> 
> 
> 
> 
> To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== .



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

From boris at codesynthesis.com  Fri Dec 23 07:35:50 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Dec 23 07:33:24 2011
Subject: [xsde-users] xs:any and xs:anyAttribute
In-Reply-To: <DDDB9E6645DE24488B8485B41A051F471322BA5C@Mercury.usurf.usu.edu>
References: <DDDB9E6645DE24488B8485B41A051F471322B5A3@Mercury.usurf.usu.edu>
	<boris.20111222141639@codesynthesis.com>
	<DDDB9E6645DE24488B8485B41A051F471322BA34@Mercury.usurf.usu.edu>
	<DDDB9E6645DE24488B8485B41A051F471322BA5C@Mercury.usurf.usu.edu>
Message-ID: <boris.20111223141737@codesynthesis.com>

Hi Jonathan,

Jonathan Haws <Jonathan.Haws@sdl.usu.edu> writes:

> In the wildcard examples, how does the driver know that the xs:any is an
> envelope? It seems that it is fine with how it is setup now, with envelope
> being the only option.  But let's say that we have two different envelopes -
> a square and a rectangle.  How does the driver distinguish that when making
> the call to _post()?

In the wildcard example, the xsd:any content is either the 'text' or 
'binary' element, not 'envelope'. In the example the driver uses the
element name to figure out which parser to use. Look at the 
implementations of the _start_any_element() and _end_any_element()
functions -- all this is happening there. The code is also extensively
commented.


> In my situation, I have a number of possibilities.  And the stuff 
> in <detail> can be any number of things - a <color>, a <shape>, or
> something else.  Is there an example of that?  Or am I missing 
> something?

Yes, the 'text' and 'binary' elements are the examples of that.


> I guess my biggest question lies in how to get the sub-schema parsers
> tied into the main parser.  The wildcard example is not clear to me 
> on how that is done.

Again, study the implementations of the _start_any_element() and 
_end_any_element() functions.


> <event>
>   <point/>
>   <detail>
>     <!-- Varied schema(s) found in separate file is added here -->
>   </detail>
> </event>
>
> [...] 
>
> Is this a correct statement:  when the top-level parser gets to 
> the <detail> element, it recognizes that what is in <detail> 
> are xs:any fields. At this point it hands parsing off to the
> _start_any_element routine.

Yes, that's correct.


> When a valid XML tag is found, it pulls the name of that tag and
> calls the appropriate parser for that tag, then moves onto the
> next one. Is that correct?

This how it works for the normal, "statically typed" content. For
the wildcard (untyped) content, the parser simply routs all the XML
content to the _*_any_*() functions. You can then figure out what
kind of content it is (e.g., 'color', 'shape') by, for example,
comparing element names, and then forward this content to the
appropriate parser. This exactly what the 'wildcard' example does.


> Will XSD/e generate the function table for that if I provide it 
> the correct options?

No. With the wildcard content XSD/e has no knowledge of what can
possibly be there. So it is your job to figure out what it is
and decide what to do with it. Some applications, for example,
may not want to parse the (unknown) wildcard content but rather
store it in some raw XML format (e.g., DOM) in order to be able
to re-create the document.


> Again, what I am looking for is a way to setup a makefile that 
> will generate and tie together all the parsing and serialization 
> code.  Then all I need to do is write the driver.

I think for that you will need to contact some AI guys ;-).

Boris

From Jonathan.Haws at sdl.usu.edu  Fri Dec 23 17:45:39 2011
From: Jonathan.Haws at sdl.usu.edu (Jonathan Haws)
Date: Fri Dec 23 17:45:47 2011
Subject: [xsde-users] xs:any and xs:anyAttribute
In-Reply-To: <boris.20111223141737@codesynthesis.com>
References: <DDDB9E6645DE24488B8485B41A051F471322B5A3@Mercury.usurf.usu.edu>
	<boris.20111222141639@codesynthesis.com>
	<DDDB9E6645DE24488B8485B41A051F471322BA34@Mercury.usurf.usu.edu>
	<DDDB9E6645DE24488B8485B41A051F471322BA5C@Mercury.usurf.usu.edu>
	<boris.20111223141737@codesynthesis.com>
Message-ID: <DDDB9E6645DE24488B8485B41A051F471322BDE2@Mercury.usurf.usu.edu>

Boris,

Thanks for all the help.  I think the pieces are falling together in my head now.  I am seeing a few with the generated code (some schemas don't produce code that will compile).  I will post those when I get a chance to see if it is something on my end.

However, now that I have a better understanding of how things work, writing the start_any_element routines should not be a big deal.  I think my biggest hangup was seeing how things all fit together.

Thanks for the help!  I will get back into this after the holidays.

Have a Merry Christmas and a happy New Year!

Jonathan


-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Friday, December 23, 2011 05:36
To: Jonathan Haws
Cc: xsde-users@codesynthesis.com
Subject: Re: [xsde-users] xs:any and xs:anyAttribute

Hi Jonathan,

Jonathan Haws <Jonathan.Haws@sdl.usu.edu> writes:

> In the wildcard examples, how does the driver know that the xs:any is 
> an envelope? It seems that it is fine with how it is setup now, with 
> envelope being the only option.  But let's say that we have two 
> different envelopes - a square and a rectangle.  How does the driver 
> distinguish that when making the call to _post()?

In the wildcard example, the xsd:any content is either the 'text' or 'binary' element, not 'envelope'. In the example the driver uses the element name to figure out which parser to use. Look at the implementations of the _start_any_element() and _end_any_element() functions -- all this is happening there. The code is also extensively commented.


> In my situation, I have a number of possibilities.  And the stuff in 
> <detail> can be any number of things - a <color>, a <shape>, or 
> something else.  Is there an example of that?  Or am I missing 
> something?

Yes, the 'text' and 'binary' elements are the examples of that.


> I guess my biggest question lies in how to get the sub-schema parsers 
> tied into the main parser.  The wildcard example is not clear to me on 
> how that is done.

Again, study the implementations of the _start_any_element() and
_end_any_element() functions.


> <event>
>   <point/>
>   <detail>
>     <!-- Varied schema(s) found in separate file is added here -->
>   </detail>
> </event>
>
> [...] 
>
> Is this a correct statement:  when the top-level parser gets to 
> the <detail> element, it recognizes that what is in <detail> 
> are xs:any fields. At this point it hands parsing off to the
> _start_any_element routine.

Yes, that's correct.


> When a valid XML tag is found, it pulls the name of that tag and
> calls the appropriate parser for that tag, then moves onto the
> next one. Is that correct?

This how it works for the normal, "statically typed" content. For
the wildcard (untyped) content, the parser simply routs all the XML
content to the _*_any_*() functions. You can then figure out what
kind of content it is (e.g., 'color', 'shape') by, for example,
comparing element names, and then forward this content to the
appropriate parser. This exactly what the 'wildcard' example does.


> Will XSD/e generate the function table for that if I provide it 
> the correct options?

No. With the wildcard content XSD/e has no knowledge of what can
possibly be there. So it is your job to figure out what it is
and decide what to do with it. Some applications, for example,
may not want to parse the (unknown) wildcard content but rather
store it in some raw XML format (e.g., DOM) in order to be able
to re-create the document.


> Again, what I am looking for is a way to setup a makefile that 
> will generate and tie together all the parsing and serialization 
> code.  Then all I need to do is write the driver.

I think for that you will need to contact some AI guys ;-).

Boris

From Jonathan.Haws at sdl.usu.edu  Wed Dec 28 17:36:54 2011
From: Jonathan.Haws at sdl.usu.edu (Jonathan Haws)
Date: Wed Dec 28 17:37:04 2011
Subject: [xsde-users] xs:any and xs:anyAttribute
In-Reply-To: <DDDB9E6645DE24488B8485B41A051F471322BDE2@Mercury.usurf.usu.edu>
References: <DDDB9E6645DE24488B8485B41A051F471322B5A3@Mercury.usurf.usu.edu>
	<boris.20111222141639@codesynthesis.com>
	<DDDB9E6645DE24488B8485B41A051F471322BA34@Mercury.usurf.usu.edu>
	<DDDB9E6645DE24488B8485B41A051F471322BA5C@Mercury.usurf.usu.edu>
	<boris.20111223141737@codesynthesis.com>
	<DDDB9E6645DE24488B8485B41A051F471322BDE2@Mercury.usurf.usu.edu>
Message-ID: <DDDB9E6645DE24488B8485B41A051F471322C929@Mercury.usurf.usu.edu>

Boris,

Okay, here is where I am at:

I am successfully parsing any XML file that is passed in.  Right now, I am ignoring all the xs:any fields and just pulling the information out of the top-level elements (event and point).  I am also able to generate code for all the sub-schemas and have found where I can tie into the parser to start parsing the sub-schemas.  I can also generate a basic XML document that is validated to the schema.

Things are looking good.

My next question is how can I deal with name conflicts between two sub-schemas?  For example, I have two sub-schemas; one called image and one called sensor.  Both define a field of view (fov) attribute.  When I try to link both of those sub-schemas into my test application, I get "multiple definition" errors.  Can this be avoided (i.e. can I provide a way to ensure that the symbol names are unique)?  Ideally I would have something like sensor_fov_pimpl::pre() and image_fov_pimpl::pre() instead of just fov_pimpl::pre() for both schemas.  Can this be done?

I am feeling like if I can get the object files to link in, I can then start into adding my own code for the _start_any_element call.

Thanks!

Jonathan


-----Original Message-----
From: xsde-users-bounces@codesynthesis.com [mailto:xsde-users-bounces@codesynthesis.com] On Behalf Of Jonathan Haws
Sent: Friday, December 23, 2011 15:46
To: Boris Kolpackov
Cc: xsde-users@codesynthesis.com
Subject: RE: [xsde-users] xs:any and xs:anyAttribute

Boris,

Thanks for all the help.  I think the pieces are falling together in my head now.  I am seeing a few with the generated code (some schemas don't produce code that will compile).  I will post those when I get a chance to see if it is something on my end.

However, now that I have a better understanding of how things work, writing the start_any_element routines should not be a big deal.  I think my biggest hangup was seeing how things all fit together.

Thanks for the help!  I will get back into this after the holidays.

Have a Merry Christmas and a happy New Year!

Jonathan


-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Friday, December 23, 2011 05:36
To: Jonathan Haws
Cc: xsde-users@codesynthesis.com
Subject: Re: [xsde-users] xs:any and xs:anyAttribute

Hi Jonathan,

Jonathan Haws <Jonathan.Haws@sdl.usu.edu> writes:

> In the wildcard examples, how does the driver know that the xs:any is 
> an envelope? It seems that it is fine with how it is setup now, with 
> envelope being the only option.  But let's say that we have two 
> different envelopes - a square and a rectangle.  How does the driver 
> distinguish that when making the call to _post()?

In the wildcard example, the xsd:any content is either the 'text' or 'binary' element, not 'envelope'. In the example the driver uses the element name to figure out which parser to use. Look at the implementations of the _start_any_element() and _end_any_element() functions -- all this is happening there. The code is also extensively commented.


> In my situation, I have a number of possibilities.  And the stuff in 
> <detail> can be any number of things - a <color>, a <shape>, or 
> something else.  Is there an example of that?  Or am I missing 
> something?

Yes, the 'text' and 'binary' elements are the examples of that.


> I guess my biggest question lies in how to get the sub-schema parsers 
> tied into the main parser.  The wildcard example is not clear to me on 
> how that is done.

Again, study the implementations of the _start_any_element() and
_end_any_element() functions.


> <event>
>   <point/>
>   <detail>
>     <!-- Varied schema(s) found in separate file is added here -->
>   </detail>
> </event>
>
> [...] 
>
> Is this a correct statement:  when the top-level parser gets to 
> the <detail> element, it recognizes that what is in <detail> 
> are xs:any fields. At this point it hands parsing off to the
> _start_any_element routine.

Yes, that's correct.


> When a valid XML tag is found, it pulls the name of that tag and
> calls the appropriate parser for that tag, then moves onto the
> next one. Is that correct?

This how it works for the normal, "statically typed" content. For
the wildcard (untyped) content, the parser simply routs all the XML
content to the _*_any_*() functions. You can then figure out what
kind of content it is (e.g., 'color', 'shape') by, for example,
comparing element names, and then forward this content to the
appropriate parser. This exactly what the 'wildcard' example does.


> Will XSD/e generate the function table for that if I provide it 
> the correct options?

No. With the wildcard content XSD/e has no knowledge of what can
possibly be there. So it is your job to figure out what it is
and decide what to do with it. Some applications, for example,
may not want to parse the (unknown) wildcard content but rather
store it in some raw XML format (e.g., DOM) in order to be able
to re-create the document.


> Again, what I am looking for is a way to setup a makefile that 
> will generate and tie together all the parsing and serialization 
> code.  Then all I need to do is write the driver.

I think for that you will need to contact some AI guys ;-).

Boris


From boris at codesynthesis.com  Thu Dec 29 09:22:13 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Thu Dec 29 09:22:51 2011
Subject: [xsde-users] xs:any and xs:anyAttribute
In-Reply-To: <DDDB9E6645DE24488B8485B41A051F471322C929@Mercury.usurf.usu.edu>
References: <DDDB9E6645DE24488B8485B41A051F471322B5A3@Mercury.usurf.usu.edu>
	<boris.20111222141639@codesynthesis.com>
	<DDDB9E6645DE24488B8485B41A051F471322BA34@Mercury.usurf.usu.edu>
	<DDDB9E6645DE24488B8485B41A051F471322BA5C@Mercury.usurf.usu.edu>
	<boris.20111223141737@codesynthesis.com>
	<DDDB9E6645DE24488B8485B41A051F471322BDE2@Mercury.usurf.usu.edu>
	<DDDB9E6645DE24488B8485B41A051F471322C929@Mercury.usurf.usu.edu>
Message-ID: <boris.20111229161755@codesynthesis.com>

Hi Jonathan,

Jonathan Haws <Jonathan.Haws@sdl.usu.edu> writes:
 
> My next question is how can I deal with name conflicts between two 
> sub-schemas?  For example, I have two sub-schemas; one called image
> and one called sensor. Both define a field of view (fov) attribute. 
> When I try to link both of those sub-schemas into my test application,
> I get "multiple definition" errors.  Can this be avoided (i.e. can I
> provide a way to ensure that the symbol names are unique)?  Ideally
> I would have something like sensor_fov_pimpl::pre() and 
> image_fov_pimpl::pre() instead of just fov_pimpl::pre() for both
> schemas.  Can this be done?

You can use the --namespace-map XSD/e option[1] to place the generated
code for each sub-schemas into a separate C++ namespace. The names
then could be: sensor::fov_pimpl and image::fov_pimpl.

[1] http://www.codesynthesis.com/projects/xsde/documentation/xsde.xhtml

Boris

From Jonathan.Haws at sdl.usu.edu  Thu Dec 29 18:45:00 2011
From: Jonathan.Haws at sdl.usu.edu (Jonathan Haws)
Date: Thu Dec 29 18:45:11 2011
Subject: [xsde-users] xs:any and xs:anyAttribute
In-Reply-To: <boris.20111229161755@codesynthesis.com>
References: <DDDB9E6645DE24488B8485B41A051F471322B5A3@Mercury.usurf.usu.edu>
	<boris.20111222141639@codesynthesis.com>
	<DDDB9E6645DE24488B8485B41A051F471322BA34@Mercury.usurf.usu.edu>
	<DDDB9E6645DE24488B8485B41A051F471322BA5C@Mercury.usurf.usu.edu>
	<boris.20111223141737@codesynthesis.com>
	<DDDB9E6645DE24488B8485B41A051F471322BDE2@Mercury.usurf.usu.edu>
	<DDDB9E6645DE24488B8485B41A051F471322C929@Mercury.usurf.usu.edu>
	<boris.20111229161755@codesynthesis.com>
Message-ID: <DDDB9E6645DE24488B8485B41A051F471322CFFD@Mercury.usurf.usu.edu>

I tried the following rule in my makefile:

CoT_%.hxx CoT_%.cxx \
CoT_%-pskel.hxx CoT_%-pskel.cxx \
CoT_%-pimpl.hxx CoT_%-pimpl.cxx \
CoT_%-sskel.hxx CoT_%-sskel.cxx \
CoT_%-simpl.hxx CoT_%-simpl.cxx: CoT_%.xsd
	xsde cxx-hybrid $(XSDFLAGS) $(EXTRA_XSDFLAGS) \
	--generate-parser --generate-serializer --generate-aggregate \
	--reserved-name major=cotmajor --reserved-name minor=cotminor \
	--namespace-map http://www.w3.org/2001/XMLSchema=$(shell echo $< | cut -d'.' -f1)::xml_schema $<

The sub-schemas build okay, but the sensor and image schemas still conflict.  I have found that the --namespace-map option puts all the base types in their own namespace, but the top level elements (fov, north, vfov, etc.) are still in the top-level namespace.  Here a piece of the generated code:

namespace CoT_sensor
{
  namespace xml_schema
  {
    using ::xsde::cxx::hybrid::any_type;
    typedef ::std::string any_simple_type;

    typedef signed char byte;
    using ::xsde::cxx::hybrid::byte_base;

    typedef unsigned char unsigned_byte;
    using ::xsde::cxx::hybrid::unsigned_byte_base;

    typedef short short_;
    using ::xsde::cxx::hybrid::short_base;

    typedef unsigned short unsigned_short;
    using ::xsde::cxx::hybrid::unsigned_short_base;

    typedef int int_;
    using ::xsde::cxx::hybrid::int_base;

    typedef unsigned int unsigned_int;
    using ::xsde::cxx::hybrid::unsigned_int_base;

    typedef long long long_;
    using ::xsde::cxx::hybrid::long_base;

    typedef unsigned long long unsigned_long;
    using ::xsde::cxx::hybrid::unsigned_long_base;

    typedef long integer;
    using ::xsde::cxx::hybrid::integer_base;

    typedef long non_positive_integer;
    using ::xsde::cxx::hybrid::non_positive_integer_base;

    typedef unsigned long non_negative_integer;
    using ::xsde::cxx::hybrid::non_negative_integer_base;

    typedef unsigned long positive_integer;
    using ::xsde::cxx::hybrid::positive_integer_base;

    typedef long negative_integer;
    using ::xsde::cxx::hybrid::negative_integer_base;

    typedef bool boolean;
    using ::xsde::cxx::hybrid::boolean_base;

    typedef float float_;
    using ::xsde::cxx::hybrid::float_base;

    typedef double double_;
    using ::xsde::cxx::hybrid::double_base;

    typedef double decimal;
    using ::xsde::cxx::hybrid::decimal_base;

    typedef ::std::string string;

    typedef ::std::string normalized_string;

    typedef ::std::string token;

    typedef ::std::string name;

    typedef ::std::string nmtoken;

    typedef ::xsde::cxx::string_sequence nmtokens;

    typedef ::std::string ncname;

    typedef ::std::string language;

    typedef ::std::string id;

    typedef ::std::string idref;

    typedef ::xsde::cxx::string_sequence idrefs;

    typedef ::std::string uri;

    using ::xsde::cxx::qname;

    using ::xsde::cxx::buffer;
    typedef ::xsde::cxx::buffer base64_binary;
    typedef ::xsde::cxx::buffer hex_binary;

    using ::xsde::cxx::time_zone;
    using ::xsde::cxx::date;
    using ::xsde::cxx::date_time;
    using ::xsde::cxx::duration;
    using ::xsde::cxx::gday;
    using ::xsde::cxx::gmonth;
    using ::xsde::cxx::gmonth_day;
    using ::xsde::cxx::gyear;
    using ::xsde::cxx::gyear_month;
    using ::xsde::cxx::time;

    using ::xsde::cxx::hybrid::pod_sequence;
    using ::xsde::cxx::hybrid::fix_sequence;
    using ::xsde::cxx::hybrid::var_sequence;
    using ::xsde::cxx::string_sequence;
    using ::xsde::cxx::hybrid::data_sequence;
  }
}

All the xsde stuff is put in there, but that is not what is conflicting.  It is the class definitions for the elements/attributes that get defined after this block that are conflicting.

Any thoughts?  Am I using the option wrong?  What I want is to get everything that is generated by the xsde call to be wrapped in a separate namespace.  Can that be done?

Thanks!

Jonathan


-----Original Message-----
From: Boris Kolpackov [mailto:boris@codesynthesis.com] 
Sent: Thursday, December 29, 2011 07:22
To: Jonathan Haws
Cc: xsde-users@codesynthesis.com
Subject: Re: [xsde-users] xs:any and xs:anyAttribute

Hi Jonathan,

Jonathan Haws <Jonathan.Haws@sdl.usu.edu> writes:
 
> My next question is how can I deal with name conflicts between two 
> sub-schemas?  For example, I have two sub-schemas; one called image 
> and one called sensor. Both define a field of view (fov) attribute.
> When I try to link both of those sub-schemas into my test application, 
> I get "multiple definition" errors.  Can this be avoided (i.e. can I 
> provide a way to ensure that the symbol names are unique)?  Ideally I 
> would have something like sensor_fov_pimpl::pre() and
> image_fov_pimpl::pre() instead of just fov_pimpl::pre() for both 
> schemas.  Can this be done?

You can use the --namespace-map XSD/e option[1] to place the generated code for each sub-schemas into a separate C++ namespace. The names then could be: sensor::fov_pimpl and image::fov_pimpl.

[1] http://www.codesynthesis.com/projects/xsde/documentation/xsde.xhtml

Boris

From boris at codesynthesis.com  Fri Dec 30 08:26:40 2011
From: boris at codesynthesis.com (Boris Kolpackov)
Date: Fri Dec 30 08:27:12 2011
Subject: [xsde-users] xs:any and xs:anyAttribute
In-Reply-To: <DDDB9E6645DE24488B8485B41A051F471322CFFD@Mercury.usurf.usu.edu>
References: <DDDB9E6645DE24488B8485B41A051F471322B5A3@Mercury.usurf.usu.edu>
	<boris.20111222141639@codesynthesis.com>
	<DDDB9E6645DE24488B8485B41A051F471322BA34@Mercury.usurf.usu.edu>
	<DDDB9E6645DE24488B8485B41A051F471322BA5C@Mercury.usurf.usu.edu>
	<boris.20111223141737@codesynthesis.com>
	<DDDB9E6645DE24488B8485B41A051F471322BDE2@Mercury.usurf.usu.edu>
	<DDDB9E6645DE24488B8485B41A051F471322C929@Mercury.usurf.usu.edu>
	<boris.20111229161755@codesynthesis.com>
	<DDDB9E6645DE24488B8485B41A051F471322CFFD@Mercury.usurf.usu.edu>
Message-ID: <boris.20111230152206@codesynthesis.com>

Hi Jonathan,

Jonathan Haws <Jonathan.Haws@sdl.usu.edu> writes:

> --namespace-map http://www.w3.org/2001/XMLSchema=...

This option maps the Schema namespace (http://www.w3.org/2001/XMLSchema)
to a C++ namespace. You don't need to do this. What you need to do is
map the COT schema namespace to different C++ namespaces for each schema.
I have an old version (2.0) of COT schemas and I see they don't use XML
namespaces (there is no targetNamespace attribute). If that still holds,
then you will need to use something like this:

--namespace-map =sensor (when compiling the sensor schema)
--namespace-map =image (when compiling the image schema)

Boris