Return-Path: <hvendelbo@bluprints.com>
Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list tomcat-dev@jakarta.apache.org
Received: (qmail 12470 invoked from network); 12 Oct 1999 20:56:48 -0000
Received: from ethem.lightrealm.com (HELO nuconcept.dk) (216.122.80.2)
  by apache.org with SMTP; 12 Oct 1999 20:56:48 -0000
Received: from pixie.bluprints.com (ip243.hinxr3.ras.tele.dk
 [195.249.202.243])
	by nuconcept.dk (8.8.7/8.8.5) with SMTP id WAA28490
	for <tomcat-dev@jakarta.apache.org>; Tue, 12 Oct 1999 22:55:26 +0200 (CEST)
From: Henrik Vendelbo <hvendelbo@bluprints.com>
Date: Tue, 12 Oct 1999 20:52:00 GMT
Message-ID: <19991012.20520073@pixie.bluprints.com>
Subject: Re: XML/DTD/XSchema
To: tomcat-dev@jakarta.apache.org
In-Reply-To: <19991012162441.A21848@sba.miami.edu>
References: <19991012162441.A21848@sba.miami.edu>
X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.1; Win32)
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Nice suggestion.

A variation is that only defined structures are checked against

<tag1 x=3D"10" y=3D"12">
  <subtag/>
</tag1 >

<tag2 z=3D"44"/>

now if tag1 is defined (and the above tag1 is legal re definition)=20
while tag2 has not been defined,=20
then the configuration is legal.

This approach would allow for experimentation and enforcing structure=20=

gradually as modules mature.


>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 12-10-99, 20:24:41, Troy Poppe <troy@sba.miami.edu> wrote regarding=20=

XML/DTD/XSchema:


> Have we considered the possibility of 'building' the=20
DTD/XSchema/whatever
> (hereafter refered to as a definition) at runtime when the XML=20
configuration
> information is parsed?  Each module of the server (framework) would=20=

have its
> own definition specs (ie. what tags are valid where).  Given some=20
interface
> (what we hope to define), a module registers what elements are valid, =

what
> are not, their contexts, etc. with this service.  The service then in =

turn
> generates a valid definition for use as a server definition.

> At that point it is up to the service for how to implement this (and I=
=20
know
> that this is still a major point).

> It would seem that this would give a fair amount of abstraction, and=20=

allow
> for some powerful extensibility.

> - Troy



> ---------------------------------------------------------------------=

> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org