jakarta-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From eba...@us.ibm.com
Subject Re: Jakarta/Apache XML/RDF configuration file format(s)
Date Mon, 12 Jul 1999 17:28:16 GMT



Thans for the clarification on XML Schemas...  The schemas I refered to in my
earlier note are strictly  DTDs.


Cheers,
-Elias


IBM WebSphere Application Server

(919) 254-  (tie 444) 9179 (Office)
(919) 696-3390 (Pager/Cell)
net.Meeting address (audio/video): elias.raleigh.ibm.com

"Simplicity is often the result of profound thought"




Dan Brickley <Daniel.Brickley@bristol.ac.uk> on 07/12/99 12:55:11 PM

Please respond to general@jakarta.apache.org

To:   general@jakarta.apache.org
cc:    (bcc: Elias Bayeh/Raleigh/IBM)
Subject:  Re: Jakarta/Apache XML/RDF configuration file format(s)






The term 'schema' has been sprayed around so broadly in XML circles that
it is best to qualify usage, eg "XML Schema" capitalised to refer to the
work-in-progress of the XML Schema W3C working group. XML Data and
XML-Data-reduced can reasonably claim to describe one way of doing XML
schemata. DTDs can be thought of as the unfashionable old way of doing
it. There are numerous other schema proposals (SOX,DDML,DCD).
RDF [1], which which I'm most familiar, uses the term 'schema' in a
slightly different manner (doh!) sketched below.

In RDF schemas, we use RDF to provide descriptive and constraining
meta-information about classes of thing and the properties that make
sense when applied to those things. This currently only connects with XML at
the serialising-data-into-conrete-syntax level. In other words, RDF
schemas might say that the 'port' property makes sense when applied to
resources that are members of the class 'NetworkService' and when it
has a value that is an Integer. An XML schema (of whichever kind) will
generally couch such a constraint in terms of the XML elements and
attributes that can represent this is concrete angle-bracketted syntax.
There is some overlap between these two approaches, clearly, and much
current headscratching on best way to proceed with the two
specifications (see URL below).

RDF and RDF schema don't themselves define many rich sorts of constraint
(regex match, data, int, float etc). I believe the expectation is that
the XML Schema WG will come up with something that can have a natural
interpretation in XML so that both XML and RDF can share some
data-typing and constraint machinery. The details of this have not yet
been worked out yet. Consequently we're in a position where there is no
immediately applicable spec that'll do everything we want. XML Schema is
some time off; RDF Schema lacks rich constraints until XML datatypes
etc are done; DTDs are too weak for many people's requirements.

BTW, I posted an 'RDF status' note to the RDF Developers list last month
with a couple of refs to documents on the W3C site that shed some light on
this. See http://www.mailbase.ac.uk/lists/rdf-dev/1999-06/0026.html

Dan


[1] http://www.w3.org/RDF/

 On Mon, 12 Jul 1999, Sanjiva Weerawarana wrote:

> We are currently using a DTD. The schema spec is in a first draft
> stage and AFAIK no code supports it. (IE5 supports XMLData-reduced,
> which is different from the schema WG's work yet.) We will use a
> DTD, but a DTD cannot capture everything - so its DTD + comments
> in natural language (English) until schema goes live.
>
> Sanjiva.
>
> -----Original Message-----
> From: dion@multitask.com.au <dion@multitask.com.au>
> To: general@jakarta.apache.org <general@jakarta.apache.org>
> Date: Monday, July 12, 1999 12:30 PM
> Subject: Re: Jakarta/Apache XML/RDF configuration file format(s)
>
>
> >Elias, are you using "XML Schema" or a "DTD". The two are very separate
> >things.
> >
> >See http://www.xml.com/xml/pub/1999/07/schemas/index.html for more info.
> >--
> >dIon Gillard, Multitask Consulting
> >Work:      http://www.multitask.com.au
> >Play:        http://www.trongus.com
> >
> >----- Forwarded by dIon Gillard/Multitask Consulting/AU on 13/07/99 02:25
> >AM -----
> >Stefano,
> >
> >We are currently defining an XML schema (DTD) to configure the Websphere
> >Application Server Web (Servlet and JSP) engine...  I don't want to invent
> >something unique to IBM if we can use (or corraborate) on a standard
> >Schema.  I
> >will be happy to post our first pass at a DTD if anyone is interested.
> >
> >For web applications,  we will use the standard schema posted in the 2.2
> >spec.
> >
> >
> >Cheers,
> >-Elias
> >
> >
> >Stefano Mazzocchi <stefano@apache.org> on 07/12/99 06:00:44 AM
> >
> >Please respond to general@jakarta.apache.org
> >
> >To:   general@jakarta.apache.org
> >cc:   "Eric Prud'hommeaux" <eric@w3.org>, Daniel Lopez Ridruejo
> >      <ridruejo@bart.us.es> (bcc: Elias Bayeh/Raleigh/IBM)
> >Subject:  Re: Jakarta/Apache XML/RDF configuration file format(s)
> >
> >
> >
> >
> >
> >
> >Dan Brickley wrote:
> >
> >> Is the detail of the XML format finalised, or up for discussion? There
> >> was some talk last autumn of an XML/RDF representation of Apache
> >> configuration files.
> >
> >A little history might help:
> >
> >During the ApacheCon '98 party at the SF Exploratorium (in October),
> >Eric and I talked a lot about XML and the new stuff the W3C was
> >creating. Eric is a very smart guy and we shared lots of ideas about how
> >the web was going and how we could use those new technologies to do
> >better things. (Some of that very early discussion made me create Cocoon
> >a few months later to investigate it further, but this is another
> >story).
> >
> >We both agreed that XML was a major move forward and given its
> >simple-yet-powerful syntax and structure, it could really be used for
> >XML configurations (at that time, some of the Apache folks were not
> >satisfied by the three-files Apache configurations and wanted to move
> >forward for Apache 2.0. XML was proposed as a choice) and all a bunch of
> >other things.
> >
> >At the same event, Daniel was showing its new Comanche and showed me how
> >he had some "configuration wrappers" that allowed its engine to be very
> >flexible and abstracted on the real configurations. (we had discussed
> >this privately the summer before when I was trying to start off a new
> >Swing-based configuration project for JServ under java.apache called
> >"Jack - Java Apache Configuration Kit" but went nowhere).
> >
> >It was simple to associate this meta-configuation separatation model
> >with what the W3C was doing. So Erid, Daniel, Pierpaolo and I spent a
> >whole afternoon to find out the best way to do it. (Eric later set up
> >the mail list you were indicating). As you see, those ideas have been
> >around for a while and if we move Jakarta into the configurations-in-XML
> >world, this is something we should seriously investigate since it would
> >allow people (and vendors) to contribute with such configuration tools
> >in a very abstracted way.
> >
> >Here is a simple configuration file to show what I mean:
> >
> > <server>
> >  <name>jakarta.apache.org</name>
> >  <port>80</port>
> >  <admin>jakarta@apache.org</admin>
> > </server>
> >
> >Given the configuration DTD, you might use XML tools (such as IBM Xeena)
> >to edit these elements in a valid way, but DTD are very limited because
> >they validate the XML structure and not the internal rules.
> >
> >So you need to come out with something that allows a configuration tool
> >(might be GUI or text based) a way to present information in an
> >interactive way (use TextField or ComboBox, etc..) and to validate it
> >against some strict rules (1 < port < 64K, admin content is a valid mail
> >address, etc..)
> >
> >If all this information is based on a common meta-configuration
> >definition language (Eric thought about RDF for this, but I don't know
> >RDF enough to express a final opinion on this), then one tool may be
> >used to configure every possible software that can express such RDF for
> >its configurations.
> >
> >This is so flexible (being on different files) that old vi-style people
> >are not bothered by unnecessary information in their XML configuration
> >file, but people willing to use more coherent tools (such as Comanche)
> >for different software in their network. This tool might also be nicely
> >wrapped by SNMP logic and so on.
> >
> >The key point is the separation of configurations (in XML with some DTD)
> >parsed by the configured software and meta-configurations (in another
> >XML using the RDF DTD) parsed by whatever configuration tool. An
> >important thing is that meta-configurations are used as "templates" for
> >the creation of an XML configuration and might even be used by
> >installers to present interactive information to the user during
> >installation.
> >
> >For example (I'm not using RDF for this, just to show my intentions):
> >
> > <element name="port" required="true">
> >  <template-value>80</template-value>
> >  <gui type="counter">
> >  <comment xml:lang="en">This is the port used by the server</comment>
> >  <comment xml:lang="it">Questa h la porta usata dal server</comment>
> >  <comment xml:lang="fr">Cette est la porte utilishe par le
> >serveur</comment>
> > </element>
> >
> >as you see, a configuration tool that is able to interpret this document
> >would be able to generate the <port> element and query the user
> >(depending on its language).
> >
> >Unfortunately, the list is dead for some time now. But the ideas, IMO,
> >as still solid and useful.
> >
> >P.S. Eric, Daniel, sorry to make you jump on this. For more information
> >about Jakarta, look at jakarta.apache.org. Send any comment to me and
> >I'll forward to the mail list (or you might consider to subscribe to the
> >list if interested)
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: general-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>


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





Mime
View raw message