Re: [xsl] Hiding XML to an application (serialization?)

[James Fuller <jim.fuller@xxxxxxxxxxxxxx>]

Angel Gavin wrote:

>Hi,
>
>I have an application that consists of two components, say A and B.
>Component A is a kind of monitoring and control system. It reads application
>configuration files (in XML; customer requirement), keeps these files
>updated (e.g., updating values on user request) and call component B with
>(relevant) configuration parameters. The point is that we want to keep
>component A as much independent as possible from the XML "vocabulary" used
>in configuration files. In doing so, changes in file definition (e.g., new
>parameters) will not (ideally) affect component A. Component A is going to
>be developed by a third party, and the idea behind this is that we do not
>want to request a change in A in case we discover we have to add, say, a new
>configuration parameter.
>  
>
parameterisation is always a good approach irregardless of data format
or how it is manipulated.

>Lessons learnt in the past show that changing A is (irremediably) more
>frequent than expected. I think we can manage configuration files quite well
>by defining a set of XSLT scripts to do the dirty work (we would assume this
>activity), and then component A would only have to know which is the script
>to be executed, its input and input/output XML files. Perhaps
>this solution is quite twisted, but it is supposed to work, isn't it? Any
>hint will be much appreciated.
>  
>
u do not have to use xslt if u just want to marshall simple
configuration data into an application, depending upon the programming
environment there are many tools to 'slurp' up an xml file and
objectify/arrayfy into internal data representation.

u could use XSLT to generate the final xml configuration files quite
easily though

>Concerning the second part of the problem (calling B with relevant
>configuration data), the good news are that we develop this component (and
>its interfaces) but I am afraid that:
>
>- B cannot read data from files
>  
>
dont think of XML as a file format....it can live in a database, inside
most programming environments....by orientating your architecture around
the concept of files you maybe limiting yourself for no reason.

>- My colleagues in charge of the "B thing" do not want to receive data in
>XML. For sure there is a good reason for that (dunno!), but at the end the
>problem is the same. I feel a bit stupid playing around with this, but the
>point is that we want A to be independent of XML file structure, passing
>data to B in a "non-XML fashion" (the XSLT trick above will not work).
>  
>
like i said there are plenty of ways of marshalling data back and forth
from xml to whatever

>I've been reading something about serialization. I do not know if this will
>be of help or not (far from being an expert on this; I have never used this
>stuff in my life). Any ideas?
>  
>
serialisation is just the marshalling of data from one format to
another, lets use an example with Objects in the OO sense....lets say your
program creates a bunch of objects which u want to persist after the
program stops executing saving some sort of state information...one
method of doing this is to serialise the object to some out of memory
format (lets say binary or perhaps xml).

I would start (as with any application) designing the configuration data
into the simplest possible xml format, then take whatever platform
specific tool to slurp up xml and turn it into a string|array|object
(castor is a good java example...xml beans etc).

good luck, Jim Fuller