Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: so many options no idea where to begin
 Tim Bray wrote: > > Rick Jones wrote: > > yet another newbie stumbles into the maze of twisty TLA's all similar > > but different... > > This is so refreshingly different from the theological exegesis usually > practiced around here. That just zoomed miles above my head, and I am often described as utilizing polysyllabic verbiage in interpersonal communications :) > > long ago and far away (first public distribution in 1993), i > > wrote/edited a benchmark called netperf (http://www.netperf.org/) > > Heh-heh in 1990 I wrote Bonnie, now in yer basic linux distro, still > gloriously free of anything but line-oriented input and output. Hmmm Amazing how a good idea has legs isn't it :) > > now I'm looking to abstract further, and someone suggested that XML may > > be the way to go. i am looking for a more flexible config format and > > message passing mechanism, and reporting. > > Yup, seems like if you're going to go to the work of rejiggering this > stuff, you might as well XMLify it, the alternative is inventing your > own new syntax which is just not a good way to spend time. And these days I feel compelled to be able to add new TLAs to my resume... > > notice that there is a dependency between test 2 and test 1 - test 2 > > needs to know what the dynamically alolcated port number used by test 1 > > happens to be before it can establish the data connection. > > Right, so the sequence is important. Right off, you have to decide > whether the whole exchange is one big XML doc from start to end, or > whether you're going to open a channel and send along a series of > smaller XML docs. I suspect the latter will be slightly less > programming work - you can bash each little XML message into a DOM or > other in-mem structure as it arrives, whereas in the on-doc approach > you're really going to need to deal with individual elements as they > show up on the wire. I figure the intial configuation data is (at least conceptually) one big XML document and the netperf controller would have one big in-mem structure (presently what libxml2 would give me). Indeed, I figured on sending mini-docs of XML to the individual tests. The reason I mentioned the interdependence between some tests was an obtuse way of trying to ask about ID and IDREF attributes I suppose. When it comes time in the netperf controller to send setup information to the dependent test I want to be able to lookup the dependent stuff with reasonable simplicity and dispatch. I figured then that I would need/want to use ID and IDREF attributes. > > using XML as the output format of the benchmark appears appealing - the > > stuff I wrote to parse netperf2 output for the netperf database was, > > well, quaint. > > Yep, probably the best reason. > > In your example: I'm not sure why it's a good idea to put > platform-specific stuff into separate namespaces. Not sure it's a bad > idea either, but aren't a lot of them going to share a lot of fields? Well, I sort of slid into the idea of using namespaces. Basically, I wanted some way to isolate/identify test-specic things such that while the netperf controller was parsing the big config file (or intially parsing a message) it could see "ah hah, this part is only groked by the nettest_bsd test-specific "parser" - I wanted to layer/isolate/whatever things so netperf itself wouldn't necessarily need to know about it directly. I was also hoping that there would be some way to have the test-specific portions covered by their own validation rules such that the existing XML/XSDL parsers/validators might do some of the config file and message checking for me. > > *) i'm not sure when one "should" use attributes versus a nested element > > Someone already pointed you at Robin's assemblage, which you should > read. The important thing is not to lose sleep over it because (gasp) > it isn't that important. OK. rick jones -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
