[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

• To: xml-dev@l...
• Subject: Re: so many options no idea where to begin
• From: Rick Jones <rick_jones2@h...>
• Date: Wed, 31 Jul 2002 10:21:24 -0700
• Organization: the Unofficial HP
• References: <3D472E5B.626CA56B@h...> <007e01c2382e$95fcd0e0$fe193044@tbp1>
• Reply-to: raj@c...
• Sender: raj@t...

"Thomas B. Passin" wrote:
> 
> [Rick Jones wrote long and thusly -]
> >...
> > <!-- I would like to be able to include a file of just test and
> > server elements without a containing <netperf></netperf> -->
> 
> Ultimately an xml file has to exactly one root element, so at some
> point you have to end up with one.

I can accept that, I just don't want to have another root element as a
subelement of the including document

> > *) i'm not sure when one "should" use attributes versus a nested 
> >    element
> >
> 
> Ah, always good for an argument!  There are two points of view:

I thought it might be :)

> 1) Use attributes when the data is flat - i.e., just name/value pairs.
> 2) Use attributes to annotate their elements, that is, as a kind of
>    meta data.
> 
> There are very good aguements to be made for both viewpoints.
> 
> I would say just do not worry about it, but if your data is completely
> flat you may want to think about whether you need XML at all (but it
> will probably turn out to be more flexible and useful than you expect).

That is my hope. While my config file isn't going to be the Marianas
Trench in depth, it isn't quite flat.

> If you always expect to keep all the data values together as a group,
> it matters the least whether you use elements or attributes.  If you
> think you may want to rearrange and subset data items, elements will
> probably make that easier, at least if they have some logical
> relationship that can be expressed by containment (I mean, as child
> elements).

I guess I'm leaning towards 2 - make something like the address family
an attribute of the hostname, have a units attribute for socket buffer
and send sizes and such.

> > *) 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)
> >
> 
> To me this begs to be handled with xslt. 

Gaak, YATLA :)

> You would write a simple driver file (in xml) for each test suite that
> you want to instantiate.  You run the driver against a stylesheet.  The
> stylesheet would take care of pulling in all the parts, to the desired
> depth, customizing, and assembling them.  The only drawback is that
> xslt is one more thing to learn, and as an oldline C person it may seem
> foreign and strange.   But you can get plenty of help!  I have gotten
> very fond of xslt, to my surprise.

I'll keep that in mind and will probably go that route in phase two or
something. 

> > *) 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.
> >
> 
> Depends on how you want to use it.  You could always do a system call
> and parse the return from stdout.

What, do something Unix-like?-)

> > *) 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?
> >
> 
> Namespaces - hmm - you would have to say more about what you need to
> distinguish by using namespaces.  I do not think you need to be
> "concerned", but you have to work out where they will be, if you will
> have one schema that imports others, and such-like matters.  If you had
> different classes of tests that were structured fundamentally
> differently from each other, you might use different namespaces for
> them, with one for common things like network parameters, but I do not
> thing you will find much need for many namespaces.  Besides, once you
> have decided what they are they will be fixed, I would think.

OK, I'll not worry about namespaces just yet.

thanks for the tips

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

• Follow-Ups:
  • Re: so many options no idea where to begin
    • From: John Cowan <jcowan@r...>

• References:
  • so many options no idea where to begin
    • From: Rick Jones <rick_jones2@h...>
  • Re: so many options no idea where to begin
    • From: "Thomas B. Passin" <tpassin@c...>

• Prev by Date: RE: The BBQ Proposition was Re: Re: URIs,concrete
• Next by Date: RE: Data mining the semantic web? (was RE: Se mantic Web)
• Previous by thread: Re: so many options no idea where to begin
• Next by thread: Re: so many options no idea where to begin
• Index(es):
  • Date
  • Thread