gunman69
asked on
Options to generate XML data from tabular data
Hi!
We have a functional requirement to implement an XML-generation from tabular data, in .NET.
Non-functional requirements are that the schema of the XML-document, and the mapping between the fields in the tabular data and the elements/attributes must be “as dynamic as possible”, without having too much effect on the performance.
For instance, consider the following tabular data (this is very simplified, just to show the point):
Table “Model”
ModelName Manufacturer
V70 Volvo
XC60 Volvo
Clio Renault
Espace Renault
Table “Car”
ModelName Year Color
V70 2009 Red
V70 2008 Black
XC60 2003 Silver
Clio 2001 Red
Espace 2002 Grey
Espace 2003 Black
This could generate the following XML-document:
<Models>
<Model name="V70" manufacturer="Volvo">
<Cars>
<Car year="2009" color="Red"/>
<Car year="2008" color="Black"/>
</Cars>
</Model>
<Model name="XC60" manufacturer="Volvo">
<Cars>
<Car year="2003" color="Silver"/>
</Cars>
</Model>
...
</Models>
However, it could also be:
<Colors>
<Color name="Red">
<Cars>
<Car modelName ="V70" manufacturer = "Volvo" year = "2009" />
<Car modelName ="Clio" manufacturer = "Renault" year = "2001" />
</Cars>
</Color>
<Color name="Black">
<Cars>
<Car modelName ="V70" manufacturer = "Volvo" year = "2008" />
<Car modelName ="Espace" manufacturer = "Renault" year = "2003" />
</Cars>
</Color>
...
</Colors>
If the schema was fixed (say, the first example above), it would be easy to implement this using a traditional technique (using LinqToSql+LingToXml, for instance), thus “hard-coding” the schema into the code.
The performance would be good. However, it requires changing the code + recompiling + distributing the new DLL if the schema changes in the future.
A more dynamic approach would probably be to use XSLT-templates. Then, when the schema needs to be changed, the XSLT-template is “simply” modified according to the new schema, and this is then distributed.
Performance, however, would be worse as when using a more “hard-coded” technique.
Now, to my questions:
1. I have a feeling I am missing something an option here. If I have the XSD-schema, and the mapping between the elements in the schema and the tabular data, shouldn’t there be a really easy way to generate the XML data?
2. What would be my best option? I know there may be many answers to this, but please give me your ideas.
Thanks!
/Fredrik
We have a functional requirement to implement an XML-generation from tabular data, in .NET.
Non-functional requirements are that the schema of the XML-document, and the mapping between the fields in the tabular data and the elements/attributes must be “as dynamic as possible”, without having too much effect on the performance.
For instance, consider the following tabular data (this is very simplified, just to show the point):
Table “Model”
ModelName Manufacturer
V70 Volvo
XC60 Volvo
Clio Renault
Espace Renault
Table “Car”
ModelName Year Color
V70 2009 Red
V70 2008 Black
XC60 2003 Silver
Clio 2001 Red
Espace 2002 Grey
Espace 2003 Black
This could generate the following XML-document:
<Models>
<Model name="V70" manufacturer="Volvo">
<Cars>
<Car year="2009" color="Red"/>
<Car year="2008" color="Black"/>
</Cars>
</Model>
<Model name="XC60" manufacturer="Volvo">
<Cars>
<Car year="2003" color="Silver"/>
</Cars>
</Model>
...
</Models>
However, it could also be:
<Colors>
<Color name="Red">
<Cars>
<Car modelName ="V70" manufacturer = "Volvo" year = "2009" />
<Car modelName ="Clio" manufacturer = "Renault" year = "2001" />
</Cars>
</Color>
<Color name="Black">
<Cars>
<Car modelName ="V70" manufacturer = "Volvo" year = "2008" />
<Car modelName ="Espace" manufacturer = "Renault" year = "2003" />
</Cars>
</Color>
...
</Colors>
If the schema was fixed (say, the first example above), it would be easy to implement this using a traditional technique (using LinqToSql+LingToXml, for instance), thus “hard-coding” the schema into the code.
The performance would be good. However, it requires changing the code + recompiling + distributing the new DLL if the schema changes in the future.
A more dynamic approach would probably be to use XSLT-templates. Then, when the schema needs to be changed, the XSLT-template is “simply” modified according to the new schema, and this is then distributed.
Performance, however, would be worse as when using a more “hard-coded” technique.
Now, to my questions:
1. I have a feeling I am missing something an option here. If I have the XSD-schema, and the mapping between the elements in the schema and the tabular data, shouldn’t there be a really easy way to generate the XML data?
2. What would be my best option? I know there may be many answers to this, but please give me your ideas.
Thanks!
/Fredrik
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.