XML configuration (was Re: environment patch)

[Greg Stein <gs...@lyra.org>]

Ben Laurie wrote:
> 
> Greg Stein wrote:
> > For example, let's say that we have the following XML config:
> >
> > <alias>
> >   <location>/gstein</location>
> >   <directory>/home/gstein/htdocs</directory>
> > </alias>
>...
> Not sure I want to get into an XML details argument, but I'd've expected

Argument? hehe... I think we're still at the discussion stage. Wait
until somebody actually starts coding a particular direction that
another person doesn't like. *Then* we'll get to the argument stage :-)

> this to look like:
> 
> <alias location="/gstein" directory="/home/gstein/htdocs</directory"/>
> 
> Is there some reason it shouldn't be like this?

Using elements is more flexible. For example, the attribute based
version cannot do this:

<directory>
  /home/gstein/htdocs
  <nfs>
</directory>

In this case, I've let Apache know that the directory is on an NFS
mount. It can alter its behavior to take special advantage of the NFS
mount (or *not* do things which work worse on NFS mounts).

I might also want to do this:

<alias>
  <location>/gstein</location>
  <location>/backwards/compat/location</location>
  <directory>/home/gstein/htdocs</directory>
</alias>

Any attribute-based schema can be translated to an element-based schema.
Exercise for the reader.

An external tool can easily deal with either form: element- or
attribute- based. Because of this, I'd recommend element-based for its
flexibility.

> > Basically, a module can define whatever schema it would like within its
> > "command" element.
> 
> Which is cool, but what about the DTD?

DTD are for wussies.

Just kidding. Well, we strictly don't need a DTD to parse the stuff, you
know. mod_alias just looks for the appropriate child elements in the
element passed to it. If they are there, then everything's fine. If not,
then an error is raised. A few utility functions, and this process
becomes a snap:

const ap_xml_element *ap_get_child(const ap_xml_element *elem, const
char *name);
const char *ap_get_value(const ap_xml_element *elem, const char *name);

The first just returns a child element; the second could return the text
from within a child element of "elem" (e.g. get the child via
ap_get_child, then return the interior text).

Personally, I'd prefer to have the speed of a non-conforming parser
since the modules are implicitly going to be doing the validation. It
also means that we don't have to teach XML DTD construction to module
authors. They can simply monkey-see, monkey-do on the value fetching and
skip DTD construction (yes, they could probably do this with a DTD, too,
but that is parallel maintenance in my mind).

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

Re: XML configuration (was Re: environment patch)

["Life is hard, and then you die." <ro...@innovation.ch>]

> Greg Stein wrote:
> > DTD are for wussies.
> >
> > Just kidding. Well, we strictly don't need a DTD to parse the stuff, you
> > know.
[snip]
> > Personally, I'd prefer to have the speed of a non-conforming parser
> > since the modules are implicitly going to be doing the validation.

This only affects server startup time - a few milliseconds more or
less isn't going to be a problem (look at how time is spent in stat()
etc).

> > It
> > also means that we don't have to teach XML DTD construction to module
> > authors. They can simply monkey-see, monkey-do on the value fetching and
> > skip DTD construction (yes, they could probably do this with a DTD, too,
> > but that is parallel maintenance in my mind).

Yes, but this comes at a price.

> The problem is that DTDs are useful for the person who has to write the
> XML. Of course, we can make DTDs optional.

I think this is one of the major points. Config GUI's (or even a command-
line configurator) can use the DTD to know what elements are allowed,
without having to hardcode that knowledge.

Another point is that it allows for "httpd -t" to do more sensible work;
if you type

<alais>
    ...
</alais>

(Ok, so serious dislexia here), then w/o a DTD nobody will catch it,
and instead you'll just be missing an alias.

So, in my book DTD's are a Good Thing(tm).


  Cheers,

  Ronald

Re: XML configuration (was Re: environment patch)

[Ben Laurie <be...@algroup.co.uk>]

Greg Stein wrote:
> > > Basically, a module can define whatever schema it would like within its
> > > "command" element.
> >
> > Which is cool, but what about the DTD?
> 
> DTD are for wussies.
> 
> Just kidding. Well, we strictly don't need a DTD to parse the stuff, you
> know. mod_alias just looks for the appropriate child elements in the
> element passed to it. If they are there, then everything's fine. If not,
> then an error is raised. A few utility functions, and this process
> becomes a snap:
> 
> const ap_xml_element *ap_get_child(const ap_xml_element *elem, const
> char *name);
> const char *ap_get_value(const ap_xml_element *elem, const char *name);
> 
> The first just returns a child element; the second could return the text
> from within a child element of "elem" (e.g. get the child via
> ap_get_child, then return the interior text).7
> 
> Personally, I'd prefer to have the speed of a non-conforming parser
> since the modules are implicitly going to be doing the validation. It
> also means that we don't have to teach XML DTD construction to module
> authors. They can simply monkey-see, monkey-do on the value fetching and
> skip DTD construction (yes, they could probably do this with a DTD, too,
> but that is parallel maintenance in my mind).

The problem is that DTDs are useful for the person who has to write the
XML. Of course, we can make DTDs optional.

Is it possible to nest DTDs? Or would we have to construct a "master"
DTD from lots of little ones?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

Re: XML configuration (was Re: environment patch)

[Ben Laurie <be...@algroup.co.uk>]

David D'Antonio wrote:
> > Any attribute-based schema can be translated to an element-based schema.
> > Exercise for the reader.
> 
> And visa versa?

No.

> But having a DTD and a vaildating parser is kind of nice so that module
> users can get some help if their XML doesn't work properly. Are there tools
> that can generate a DTD from some "conforming" XML?

Agree, and yes (but YMMV).

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

RE: XML configuration (was Re: environment patch)

[David D'Antonio <dd...@newsedge.com>]

> -----Original Message-----
> From: new-httpd-owner@apache.org [mailto:new-httpd-owner@apache.org]On
> Behalf Of Greg Stein
> Sent: Friday, July 09, 1999 4:46 PM
> To: new-httpd@apache.org
> Subject: XML configuration (was Re: environment patch)
> 
> 
> Ben Laurie wrote:
> > 
> > Greg Stein wrote:
> > > For example, let's say that we have the following XML config:
> > >
> > > <alias>
> > >   <location>/gstein</location>
> > >   <directory>/home/gstein/htdocs</directory>
> > > </alias>
> >...
> > Not sure I want to get into an XML details argument, but I'd've expected
> 
> Argument? hehe... I think we're still at the discussion stage. Wait
> until somebody actually starts coding a particular direction that
> another person doesn't like. *Then* we'll get to the argument stage :-)

Ha! 
 
> > this to look like:
> > 
> > <alias location="/gstein" directory="/home/gstein/htdocs</directory"/>
> > 
> > Is there some reason it shouldn't be like this?
> 
> Using elements is more flexible. For example, the attribute based
> version cannot do this:
> 
> <directory>
>   /home/gstein/htdocs
>   <nfs>
> </directory>
> 
> In this case, I've let Apache know that the directory is on an NFS
> mount. It can alter its behavior to take special advantage of the NFS
> mount (or *not* do things which work worse on NFS mounts).

Wouldn't this do the same?

<directory type="nfs">
/home/dda/htdocs
</directory>

> I might also want to do this:
> 
> <alias>
>   <location>/gstein</location>
>   <location>/backwards/compat/location</location>
>   <directory>/home/gstein/htdocs</directory>
> </alias>
> 
> Any attribute-based schema can be translated to an element-based schema.
> Exercise for the reader.

And visa versa?

> An external tool can easily deal with either form: element- or
> attribute- based. Because of this, I'd recommend element-based for its
> flexibility.

I personally think some things should be attributes and some things should be
elements. In the example above, NFS is an attribute of the directory. Also,
attributes seem appropriate when choosing from a list (i.e. a directory can be
one of NFS, LOCAL, SMB, CD, etc).
 
[snip]

> DTD are for wussies.

[snip]
 
> Personally, I'd prefer to have the speed of a non-conforming parser
> since the modules are implicitly going to be doing the validation. It
> also means that we don't have to teach XML DTD construction to module
> authors. They can simply monkey-see, monkey-do on the value fetching and
> skip DTD construction (yes, they could probably do this with a DTD, too,
> but that is parallel maintenance in my mind).

But having a DTD and a vaildating parser is kind of nice so that module
users can get some help if their XML doesn't work properly. Are there tools
that can generate a DTD from some "conforming" XML?

> Greg Stein, http://www.lyra.org/

DDA

--
David D'Antonio CNE - dda@NewsEdge.com
 Some they do and some they don't and some ya just can't tell
  Some they will and some they won't and some it's just as well
						-SuperTramp