[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
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. > 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 > 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. > > 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. > > having become totally confused by C++ several times, and wanting more > low-level control over sockets than I understand is available in Java, > and wanting to use things like libcurl for the FTP and HTTP i would like > to stick with C Hear, hear. > 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? > *) 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. > *) my config files may become quite large - XInclude sounds interesting, > but a fully formed file XIncluded (at least via libxml) has the whole > file as a sub-element when what I really want (I think anyway) is the > elements in the file being included be at the same depth as the include > itself (ie up one level) XInclude is ok, but not yet widely implemented so you may have to cook your own; which wouldn't be that hard. Or you could just assemble the chunks programmatically, in your own code or via XSL. The latter is probably more flexible arechitecturally, but has the downside that you'll have to learn XSL first. I'd advise against using entities > *) since I am interested in things like doubles and 64-bit integers and > such i think i want to use XML schemas (?) but those seem to be still > rather new and not part of libxml - are they part of any other C-based > offering. Writing a schema or a DTD or a RelaxNG (check out the latter if you haven't seen it yet) is a valuable exercise for helping shake out your design in your head. Having said that, don't worry too much; just encode the numbers in text in the obvious way with digits and +/- and decimal point if required, write some human-readable documentation as to what they represent, and let the programmers figure it out. A perl programmer's just gonna dump them all into scalars anyhow :) > *) when someone adds a new test suite, I'd like them to be able to > include a validator (schema?) that will be [expletive deleted]-in to the main config > file. however, i'm concerned about what I read about namespaces (which I > think I may need/want to avoid name conflicts) and validation, and it > seems that the validators have to be all specified at the top of a > document? Practices vary. Validators are indeed good. My suspicion is you'll be happier with RelaxNG as a basis, but check out the options. Glad to hear that netperf's getting dragged into the new millenium! -Tim
|
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
|