OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] so many options no idea where to begin

[ Lists Home | Date Index | Thread Index ]

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 sucked-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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS