Can i use xslt to make generic table from this xml output

[lozina]

I have found sample online turning generic xml output to tables but they are based on the cell data being in separate text nodes, I need something that will do the same thing but the cell data is in separate attributes.

Example of what my xml output would be equivalent to:

<cars>
<car car_id="1" color="blue" make="Ford" model="Focus"/>
<car car_id="2" color="red" make="Honda" model="Accord"/>
</cars>

I want to be able to use XSLT to turn that xml into an HTML table looking like this:

car_id___|__color__|__make__|__model___|
-----------+----------+------------+------------+
1_______|__blue__|___Ford___|___Focus__|
2_______|__red___|__Honda__|___Accord_|

The thing is the xml output will change in format so the xslt must be able to do this dynamically, without any reference to node names not even knowing how many attributes there are. So while my above example is about cars with those specific attributes it should handle for example another similarly structured xml output but which maybe each node is a book and has completely different attributes. But it should handle this just the same building a simple table out of it.

It must be able to:
1. create a table header based on what attributes are sent for each node
2. iterate through each node and output the attribute values into separate cells

 

[Markbnj]

Yes, you can do that with XSLT. Start with the W3C XSLT tutorial at http://www.w3schools.com/xsl/. It will get you started.

Edit: didn't pay enough attention to your bolded text. XSLT isn't intended for XML that changes dramatically every time, but it can handle some dynamic adjustments in structure. You will need either node names, or node positions, something you can anchor the transformations too.

 

[FP]

Yes, you can do it with xslt however I would agree with Markbnj... Random xml structure will eventually break. What happens if the source decides to use multiple descendant child elements? What happens when one element doesn't have an attribute that every other element has?

Doing what you are suggesting is a bad idea and a poor design choice.

Try to get DTDs or schema files that describe the files you will be receiving. It will make your life much easier in the long run.

 

[lozina]

Yes I agree with you guys, it is not the best situation but that's the way I gotta do it.

So I know I can select attribute values based on an index like this:

@*[x] where x is the attribute's position in the tag

but how do I count how many attributes there are? Or how do I know when to stop incrementing x to grab the next attribute?

 

[Markbnj]

Originally posted by: lozina
Yes I agree with you guys, it is not the best situation but that's the way I gotta do it.

So I know I can select attribute values based on an index like this:

@*[x] where x is the attribute's position in the tag

but how do I count how many attributes there are? Or how do I know when to stop incrementing x to grab the next attribute?

I think XSLT is the wrong mechanism for what you apparently need to do. There are some tools in it that will help, i.e. iterative constructs, branching, and built-in functions. But what it is not designed to do is handle situations where the input document structure changes arbitrarily. I think I would just dive in with C# and XDocument and write a custom transform that I can easily edit when the input changes. I think you'll just drive yourself nuts trying to get XSLT to do this kind of thing.

 

[FP]

Originally posted by: lozina
Yes I agree with you guys, it is not the best situation but that's the way I gotta do it.

So I know I can select attribute values based on an index like this:

@*[x] where x is the attribute's position in the tag

but how do I count how many attributes there are? Or how do I know when to stop incrementing x to grab the next attribute?

That is exactly the problem. It is very difficult to know how many unique attributes there are in the document. It will require multiple runs over the single DOM structure which depending on the size can be horribly inefficient.

Plus the order of attributes in a given XML tag is not guaranteed. "color" maybe come before "make" in element 4 but after in element 4000. Remember, XML has no implicit ordering.

May I ask why you don't have a choice in this matter? If you truly understand what you are being asked to do then it should be no problem to suggest a better way to get the data. Garbage in -> garbage out.