[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: "Thomas B. Passin" <tpassin@c...>
• Date: Tue, 30 Jul 2002 21:07:04 -0400
• References: <3D472E5B.626CA56B@h...>

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

> <xi:include href="sub.xml" />
>
> </netperf>
> ...
> *) 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:

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

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

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

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

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

A DTD is specified at the top.  Otherwise, nothing is cut and dried.  If you
are writing the software to process the config files, you can arrange other
options.

>
> i'm sure that my questions show just how little I really understand
> about all this, so please be gentle :)
>
:-)

Cheers,

Tom P

• Follow-Ups:
  • Re: so many options no idea where to begin
    • From: Rick Jones <rick_jones2@h...>

• References:
  • so many options no idea where to begin
    • From: Rick Jones <rick_jones2@h...>

• Prev by Date: so many options no idea where to begin
• Next by Date: Re: so many options no idea where to begin
• Previous by thread: so many options no idea where to begin
• Next by thread: Re: so many options no idea where to begin
• Index(es):
  • Date
  • Thread