Return-Path: <james.todd@eng.sun.com>
Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list tomcat-dev@jakarta.apache.org
Received: (qmail 10120 invoked from network); 12 Oct 1999 22:17:32 -0000
Received: from mercury.sun.com (192.9.25.1)
  by apache.org with SMTP; 12 Oct 1999 22:17:32 -0000
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA02396
	for <tomcat-dev@jakarta.apache.org>; Tue, 12 Oct 1999 15:17:09 -0700 (PDT)
Received: from taller.eng.sun.com (taller.Eng.Sun.COM [129.144.124.34])
	by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id PAA06563
	for <tomcat-dev@jakarta.apache.org>; Tue, 12 Oct 1999 15:15:43 -0700 (PDT)
Received: from eng.sun.com by taller.eng.sun.com (SMI-8.6/SMI-SVR4)
	id PAA08652; Tue, 12 Oct 1999 15:15:42 -0700
Message-ID: <3803B352.845EAABF@eng.sun.com>
Date: Tue, 12 Oct 1999 15:16:50 -0700
From: James Todd <james.todd@eng.sun.com>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: XML/DTD/XSchema
References: <19991012162441.A21848@sba.miami.edu>
 <19991012.20520073@pixie.bluprints.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


interesting and good attributes indeed.

the way i see it unfolding, in the short term (ie xml/dtd)
is to have one dtd model we can live with within certain
bounds by which various consumers could have the same data
transformed (xslt) to a more specific and digestable format
after which the data is transformed into the native application
specific data format/objects.

this way we have a "bringing together" and common dtd yet
various consumers may require the data to be transformed
(externally and/or internall) for one reason or another.

hope this helps,

- james

Henrik Vendelbo wrote:
> 
> Nice suggestion.
> 
> A variation is that only defined structures are checked against
> 
> <tag1 x="10" y="12">
>   <subtag/>
> </tag1 >
> 
> <tag2 z="44"/>
> 
> now if tag1 is defined (and the above tag1 is legal re definition)
> while tag2 has not been defined,
> then the configuration is legal.
> 
> This approach would allow for experimentation and enforcing structure
> gradually as modules mature.
> 
> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
> 
> On 12-10-99, 20:24:41, Troy Poppe <troy@sba.miami.edu> wrote regarding
> XML/DTD/XSchema:
> 
> > Have we considered the possibility of 'building' the
> DTD/XSchema/whatever
> > (hereafter refered to as a definition) at runtime when the XML
> configuration
> > information is parsed?  Each module of the server (framework) would
> have its
> > own definition specs (ie. what tags are valid where).  Given some
> 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
> know
> > that this is still a major point).
> 
> > It would seem that this would give a fair amount of abstraction, and
> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org