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

Subject: RE: [xsl] Hiding XML to an application (serialization?)
From: "Angel Gavin" <agavin@xxxxxx>
Date: Wed, 22 Jun 2005 10:08:31 +0200
Muchas gracias Aitor.

The problem is that our application is being developed in C/C++ (not Java).
At the end, any solution will be some kind of translator between A and B (it
does not matter whether it is Java, C or XSLT!), but the point is how to do
it in the very best way (I appreciate your experience with serialization).


> -----Original Message-----
> From: Aitor San Juan [mailto:asanjuan@xxxxxxxxxxxxxx]
> Sent: 21 June 2005 16:04
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: [xsl] Hiding XML to an application (serialization?)
> Hi Angel,
> 	Some time ago I used object serialization and came up with the fact
> that having serialized a Java object then it was impossible to
> read it back
> again as a Java object after having simply recompiled the class
> that represents
> tha Java object. You might consider developping another component C to
> act as a "translator" between the needs of A and B.
> 	Regards.
> -----Mensaje original-----
> De: James Fuller [mailto:jim.fuller@xxxxxxxxxxxxxx]
> Enviado el: martes, 21 de junio de 2005 15:48
> Para: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Asunto: Re: [xsl] Hiding XML to an application (serialization?)
> 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 can live in a database, inside
> most programming 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
> 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

Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion de Seguridad de la 
Informacion siendo para uso exclusivo del destinatario, quedando 
prohibida su divulgacion copia o distribucion a terceros sin la 
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje 
 erroneamente, se ruega lo notifique al remitente y proceda a su borrado. 
Gracias por su colaboracion.
This message including any attachments may contain confidential 
information, according to our Information Security Management System,
 and intended solely for a specific individual to whom they are addressed.
 Any unauthorised copy, disclosure or distribution of this message
 is strictly forbidden. If you have received this transmission in error,
 please notify the sender immediately and delete it.

Current Thread