Flying Fox wrote:I don't think it makes much difference. It is kind of like having null fields in the database.
Of course, if the XML is intended to be XSLT'ed then there may be a difference, but I don't think it is impossible to do going either way anyway?
It's not impossible, no. I just felt that the only way in parsing it that I know what components go with what page is by virtue of their processing order, which I didn't like because it could change in the future without my knowledge, meaning a static mapping of variables when I parse this stuff.
Alternatively, I'm going to bind it to a Data Set (.net guy) and go from there.
Processing order? You mean how the nodes are ordered? Assuming you are using a DOM based parser, I would never assume that and check the existence of certain nodes.
That said, however complicated and logical you want your schema really depends on what is the intended use of the XML document. It is akin to database schema design and how normalized you want to organize your data. Strictly speaking your "type specific" nodes are just 0..1 cardinality (hope I am using the term right, I am not a strict academic like SA) so it will validate against a loose schema.
Guessing at your intent, a more "technical" design may look like this:
- Code: Select all
<text>Here's some text</text>
You get one more level to deal with, and I don't know the consequence when you pass this to a DataSet. AFAIK the more sophisticated your object relationships are, the tighter your XSD needs to be, so it adds to the complexity when you bind your stuff to the DataSet. I am guessing this is some quick code to generate ASP.NET pages? I think just doing some straight forward (though less elegant) DOM parsing will be the ticket. .NET DOM-based XML parsing and XPath stuff are really easy to use. A lot of day job is still dealing with the COM based msxml3 so yes, I can tell.
The Model M is not for the faint of heart. You either like them or hate them.
Gerbils unite! Fold for UnitedGerbilNation, team 2630.