tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Todd <james.t...@eng.sun.com>
Subject Re: XML/DTD/XSchema
Date Tue, 12 Oct 1999 22:16:50 GMT

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

Mime
View raw message