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 ]

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

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

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.


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


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

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