W3C home > Mailing lists > Public > www-rdf-config@w3.org > January to March 2000

Re: Standardized Apache DTD

From: Stefano Mazzocchi <stefano@apache.org>
Date: Wed, 19 Jan 2000 15:16:51 +0100
Message-ID: <3885C753.AC1D3E14@apache.org>
To: Chris Riley <riley@info-tools.com>
CC: www-rdf-config@w3c.org
Chris Riley wrote:
> 
> Stefano Mazzocchi wrote:
> 
> > rfi from Rich Roth wrote:
> > >
> > > Why ?  Not why XML based but why create a DTD.
> > >
> > > Coming at it from the rdf-conf/gui-dev group discussions and now being
> > > involved in a XML based VL-database project (100/1000 of megs per month per
> > > customer) - we have not being using DTD's.
> >
> > Right, we want to use XSchema.
> 
> I think there may be some confusion over the vocabulary more than anything
> else.  A DTD (XSchema, RDF or anything else) provides two important
> capabilities, a well defined published interface and a means to validate the
> instance data.  In an environment where data integrity is controlled by some
> other means ( api, etc...) then the overhead of developing and maintaining a DTD
> and implementing a validating parser may not be worth the benefits it produces.
> 
> On the other hand, if the goal is to produce an environment where custom
> applications can be developed independently, then a content based DTD describing
> the data model and it's constraints is core.  For example, httpd.conf (apache
> configuration instance) contains mandatory, optional and conditional data. To
> construct an environment where multiple independent applications access and
> modify this instance, structural constraints are required to maintain the
> integrity of the instance.  A standardize API is one way to do this, but it's
> interface is not as accessible as a DTD. Here is where the work done with XML
> parsers provide tremendous advantages.

Well, I wish it was that easy: being apache a modular software, you
can't have a single DTD unless you change it every other day, or include
every possible apache module into it, or make the DTD very loose.

XSchema provides namespace-driven validation and we think this is the
key.

> > > XML is very functional as a standard representation WITHOUT requiring a DTD
> > > - you get the benefits of all the work in XML parsers and rendering without
> > > having to lock in a data description when the situation is not ready.
> >
> > Right.
> 
> I disagree.  In the case where underlying technologies are evolving, the best
> course of action is a layered approach.  Many parts of an Apache configuration
> are easily modeled and could provide immediate benefits, others may have to be
> deferred until the underlying technologies mature.  I believe the 80/20 rule
> applies here, 20 percent of the functionality will probably take 80 percent of
> the effort, but that is no reason for not dealing with the 80 percent.

Unfortunately, you can't validate the 80% of a tag set. While DTD is
digital: all or nothing, XSchema is piecewise digital: you validate one
namespace and let the other unvalidated until it reaches stability. This
is already the path we'll use, but without namespace-driven validation
this is impossible.

> >
> >
> > > Also, please keep the GUI-DEV list apprised of your work so we can added it
> > > to the work-in-progress listgins.
> >
> > I will.
> 
> Absolutely,

But keep in mind I don't have that much time to dedicate to those
things.

I think we'll wait for ApacheCon2000 where we'll go out for another
party and spend the evening talking about this, like some of us did
before resulting in the creation of this list.

Hope to see you all there.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------
Received on Wednesday, 19 January 2000 18:09:08 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 13:35:14 EDT