[xsd-users] DOM parser for embedded environment

[Balasubramanyam, Shivakumar]

Boris,

You rock :-)  

I really like the road map you have for the embedded platform. I
recently have started investigating the embedded platform development
and hence my interest in code synthesis.

I will be more than glad to provide any input from my side. I will
provide the feedback about templates once I get better idea of the
requirements of our platform.

I would also be interested to use your tool in phases if you do have.
For instance, if you provide us object creation and objection
serialization, that itself would be great for us. We can wait for the
validation as second phase integration.

Actually, we do have one special requirement for backward capability
which is to ignore any unexpected elements (it will be great to provide
a turn on/off for this kind of validation). AFAIK, if you get an
unexpected exception, you do not continue to parse and provide only the
expected elements.

Yes, I really like the separation of C++ and Serialization; the use
cases for this are limitless. I hope this is ported to all products.

I was going to respond to your earlier email regarding WSDL. If you
provide clean separation, then WSDL 2.0 logical part could be a
combination of XSD generated C++ classes (of messages) and framework of
factory classes compliant with this spec below,
http://www.omg.org/docs/ptc/06-08-01.pdf. I guess this is far fetched
but that would be really great for applications to be totally unaware of
binding services. (this is useful even for implementation to be direct
meaning a simple function call within the process)

IMO, the future application programming interface would be WSDL. I think
it is not just limited to Web Services, since the binding could be
anything (even direct interface implementation). It should be ASDL
(Application services) :-). 

Thanks,
Shiva

-----Original Message-----
From: Boris Kolpackov [mailto:boris at codesynthesis.com] 
Sent: Wednesday, June 04, 2008 4:42 AM
To: Balasubramanyam, Shivakumar
Cc: xsd-users at codesynthesis.com
Subject: Re: [xsd-users] DOM parser for embedded environment

Hi Shiva,

Balasubramanyam, Shivakumar <sbalasub at qualcomm.com> writes:

> Do you have any timeline for this feature?

We are planning to release the first version of XSD/e with
the C++/Tree-like mapping (working name C++/Hybrid) by the
end of October. We may have something for you to try (e.g.,
a beta version) around mid-September.

> Compared to C++/Tree, some features that need to be eliminated
> are 

> boost dependency

Actually, C++/Tree mapping does not depend on boost. There are
some integration points (e.g., binary serialization) but they
are optional.


> exceptions

Yes, we plan to make the use of C++ exceptions optional just like
in our other mappings provided by XSD/e.


> optimal template usage

This is actually a feature that we are trying to decide whether
to rely on or not so your feedback is very much appreciated.
Right now it seems that it would be just too much inconvenience
not to use it in specific cases (notably to implement sequences
and smart pointers).

Do you use C++ templates in your embedded projects? If so, do
you rely on implicit or explicit instantiation? It should be
fairly straightforward for the XSD/e compiler to auto-generate
explicit template instantiation requests.


> I will be interested in understanding the features you are planning
> to support. 

The C++/Hybrid will be based on Embedded C++/Parser for parsing and 
Embedded C++/Serializer for serialization. Because these two mappings
support validation in the generated code, C++/Hybrid will also have
this feature.

In essence C++/Hybrid will consist of there parts: C++ object model
classes, parser implementations based on C++/Parser and serializer
implementations based on C++/Serializer. You will probably be happy
to know that the C++ object model will be completely detached from
parsing and serialization code ;-)

We are planning to make the C++ object model lighter-weight compared
to C++/Tree based on some of the techniques of the CORBA IDL to C++
mapping (used quite extensively in embedded systems). For example,
we will have a notion of variable and fixed length types with the
fixed-length ones being embedded and passed around by value instead
of being allocated on the heap, for example:

class point
{
  float x;
  float y;
};

class triangle
{
  point a, b, c;
};

We are also planning to use a different mapping for certain choice
and sequence constructs. For example:

<complexType name="foo">
  <sequence maxOccurs="unbounded">
    <element name="bar" type="int"/>
    <element name="baz" type="int"/>
  </sequence>
</complexType>


Will be mapped to something along these lines:

class foo
{
  class sequence_element
  {
    int bar ();
    int baz ();
  };

  typedef xsde::sequence<sequence_element> sequence_type;

  sequence_type& sequence ();  
};

Later we will most likely port over other C++/Tree features that
make sense in the embedded environment, such as binary serialization,
type customization, etc. Also let me know if there is any particular
feature that you are interested in and we will keep it in mind. 

Boris