[xsd-users] Complex Custom types

Paquette, Patrick PaquetP at navcanada.ca
Mon Dec 8 10:24:59 EST 2008


--history lesson--
I'm implementing a messaging protocol between two systems, and I have
the luxury of defining the communication mechanism and the protocol.

The two systems are: VxWorks realtime OS <-> C# .Net GUI

We started using our own custom ASCII protocol, where the model was
represented in C++ classes that compiled in both (what MS calls)
"native" C++ and .NET C++.  If anyone out there ever had to do this -
it's macro hell.  Don't do it!

So, we're abandoning this approach, and moving to XML.  .NET has their
own "xsd", but for the Real time system, we're going to use
Codesynthesis XSD.

The approach is working great, but I hit a bump in the road.
--end history lesson--

>From the example on the wiki, when types are inherited from in the same
schema, it mentions to use class templates when implementing your custom
class.  To quote:

"when types being customized are inherited from in the same schema file,
we cannot include definitions of custom types at the end of the
genearted header file..."
 "...Since the custom type definitions are included before the generated
base types (person_base, superman_base, and batman_base) are defined we
have to use class templates instead of plain classes ".

I'm trying to avoid the need to define the custom types as template
classes, as I "believe" I shouldn't have to (this is where I'm probably
wrong, but let's see what everybody else says...)
Since I'm defining the schema used between the two systems (it's not
given to me by a 3rd party), I've decided not to put it all in one
schema file.  The base "Message" complex type is defined in
"Message_base.xsd", and all sub messages are defined in "Message.xsd",
and "Message.xsd" xsd:includes Message_base.xsd.
I compile them seperately with the following Makefile:
XML_FILES := message.cxx \
             message_base.cxx

CUSTOM_TYPES := --custom-type Diagnose=/Diagnose_base \
                --custom-type Message=/Message_base
                
ROOT_ELEMENTS := --root-element message \
                 --root-element message_result 

.PHONY: quick
quick : $(XML_FILES)

$(XML_FILES): %.cxx: %.xsd
	xsdx.exe cxx-tree --output-dir . --generate-serialization
--generate-polymorphic --generate-intellisense $(ROOT_ELEMENTS)
$(CUSTOM_TYPES) --hxx-epilogue '#include "$*.hpp"' $<

clean:
	rm *.?xx 

So I just use the -hxx-epilogue to include a .hpp file that defines the
customization, for each .xsd.  I don't have the problem of the example
in the WIKI because the derived types are in a different XSD.

If I want to define a custom class for the XSD types, I write .hpp/.cpp
files for that type, add it to my CUSTOM_TYPES, and it all just works.
The problem I'm having is in the type_factory_initializer in the
message.cxx file that is generated:

static
const ::xsd::cxx::tree::type_factory_initializer< 0, char, Diagnose_base
>
_xsd_Diagnose_base_type_factory_init (
  "Diagnose",
  "");

When I parse a Message that has a "Diagnose" message in it, it creates a
new instance of Diagnose_base instead of Diagnose - which I don't want.

If I change the 3rd argument of the template initializaiton from
Diagnose_base to Diagnose, everything works great...but then I'm
modifying generated source...

Is there a flag I'm missing to have this done by xsd?  Could this be a
bug?  Am I using this tool in a way it was never intended?

I really don't want to have to use dynamic_cast to check the message
type and call my message handler from that, I'd rather use a virtual
"handle" function in Message...

Any input would be greatfull.

Patrick Paquette
Programmer
Nav Canada - Flight Inspection Engineering
Technical Systems Center
280 Hunt Club Road
Ottawa, ON
K1V 1C1
(613) 248-6939


-------------- next part --------------
A non-text attachment was scrubbed...
Name: schema.zip
Type: application/x-zip-compressed
Size: 23995 bytes
Desc: schema.zip
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20081208/1b891751/schema.bin


More information about the xsd-users mailing list