[xsd-users] License and Portability

[Klaim - Joël Lamotte]

2011/6/19 Boris Kolpackov <boris at codesynthesis.com>

> Hi Joėl,
>
> Klaim - Joėl Lamotte <mjklaim at gmail.com> writes:
>
> >  - aoslcpp : a C++ (dynamic) library providing the XML parsing, model
> (all
> > generated by xsd) and data requests (functions I'm adding)
>
> This part is tricky. From your description it sounds like this library
> can be used by itself without the aosdesigner application. If that's
> the case the question is how much and what kind of functionality you
> add (the data requests part). Will the users of this library be using
> the generated code directly or will they use it through the functions
> that you are adding? If the functionality you are adding is not
> substantial and the primary purpose of aoslcpp is to provide XML
> access (via XSD-generated code) then the FLOSSE probably won't apply.
>
> Boris
>


Well, I need to add several (tons of!) functions that will work like
xqueries or xpath requests or whatever (because there is no xpath/xquery
implementation at the moment, right? I've followed leesa library but it
don't seem to be finished yat), to gathers specific data.
The first main use is to build the "views" in aosdesigner of the data in the
xml.
I also need to provide the model to be able to build extensions (the
generators/exporters) to aosdesigner and players (separate, but most of them
will certainly not be in C++ anyway).

So, both additional functions/structures (from me) and the
model/parsing/serialization (from xsd) are necessary for all projects using
aoslcpp.
The model alone is only partially useful. I want to have it in C++ only for
allowing other tools to be built without Qt dependency.

In added quantity, I can't be precise now as I didn't linked aosdesigner and
and aoslcpp yet (because of CMake usage hell). I'm mainly working on the GUI
side at the moment but I'm getting to the parts where I need the data to
insert in the views.
What I can say is that in aosdesigner I'm building at least 10 "views"
(visually) of different aspects of the xml data, most of them requiring at
least 2 different read-only "queries".
The modifications of aosl data will be both by:
 1. manipulating the model where micro-changes have to be made (like
changing the name property of an object, or changing graphic position of
graphic objects)
 2. using a modification request for more general changes or in cases where
the modification should imply a specific logic (like when you move a node in
a scene-partition in graphics, you have to make sure the node didn't got out
of it's partition and if it did you have to unlist it from it and add it in
it's new space partition)

One basic example of 2. is that I have graphic (and non-graphic) objects
that are organized in hierarchy, so if I translate one object I need to make
sure all the sub-objects are translated too.
That can't be done without a little loop in an algorithm so it'll be one of
those modifying "requests".

I'll use serialization/parsing for saving/loading files.

I don't have a generator implementation but the idea is to analyse the model
to generate "something" : a stand-alone player or a converted format that
can be read by a specific player implementation. An aosl player will
directly read the aosl file, so that requires the model if it's in C++ (but
as said, most players will not be C++ anyway).
Both will use the query functions and certainly will require additional
specific queries (for analysing) so that's why I need to expose the model
too.

So I'm not sure if it's enough added value? Did I provide enough
informations or should I be more specific on some points?
What if I make sure any interesting read-only or writing query is
implemented in aoslcpp?

Joël Lamotte