Altova Mailing List Archives


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

From: "Aitor San Juan" <asanjuan@-------------->
To:
Date: 6/21/2005 2:04:00 PM
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 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

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.