Lists Home |
Date Index |
- From: email@example.com
- To: firstname.lastname@example.org
- Date: Tue, 18 Mar 97 13:48:20 EST
> >E.g. http://docs.su.com/ab2/alluser/ADVOSUG/@xmlChunk/113.dsl
> >does a database query into presumably DynaBase (right, Jon?).
> NO! This is DynaWeb!
Sorry for the error -- I meant DynaWeb. Honest.
> >In this case, you want a processing instruction (or some other markup)
> >to say that
> >* there is no catalog file
> > http://docs.su.com/ab2/alluser/ADVOSUG/@xmlChunk/catalog
> You *could* generate a catalog, which would point at the DTD and the
If DynaWeb had been less powerful, or you (or Jon in this case!) less
familiar with it, that may not have been an option -- with some other
SGML databases I've seen, it'd be quite hard. One way would be to have
a shell script front end that special-cases all files called "catalog"
and returns a hard-wired catalog file... but even that isn't always
easy in this world of automatically-generated CGI programs with special
hooks into the servers, so you can't simply unhook them a little.
So believe me (please!), there will be people, perhaps not using DynaWeb,
who can't or won't put a catalog file in there.
> >* the dtd is not accessible at
> > http://docs.su.com/ab2/alluser/ADVOSUG/@xmlChunk/113.dtd
> > (and _this_ is where it is...)
> >* the style sheet isn't there either
> > (and _this_ is where it is...)
> [...] It would be quite possible to resolve all of the things you
> outline above inside the configuration files (easy even).
Now do it with Astoria, Documentum, Saros DM, Texel, etc., including
handling a server login to fetch the catalog file, a server login
to fetch the style sheet, a server login to fetch the DTD, and a bunch
of impatient users. Yes, you coud say the web front ends could cache
recent login connections so they didn't log in again each time, but
generally they don't seem to do that.
Then deal with systems that can't deal with the DTD inside the database.
(if DTDs were in SGML format... but that's another issue)
> >In general, if you find yourself doing probes to see if files exist
> >using http, you've probably made a design error somewhere, as this
> >isn't a good use of http.
> >So allow the processing instructions.
> Or use catalogs.
Well, I'm not saying forbid catalogs, although I can't abide the thought of
mandating all that code for XML-compliant application. I'm suggesting
providing an alternative.
Our experience with conneting Panorama with a wide range of databases has
been that we needed to do this. Maybe if all the databases had been
built by Gavin :-) we'd have been able to stick with Catalogs, and we'd
always have known where to look for catalog even with URLs like
where d=113 is the document chunk ID, get-doc is the program, 40197 is a
PATH_INFO parameter used for versioning, and the URL for CATALOG is
and no, I'm not making this up (except I've changed the field names from
those used in any one particular currently shipping commercial system).
Panorama's default algorithm would look for
which obviously won't work in this case.
So we need to say where to find the CAALOG file so we can find where to
find the DTD. Or, we put an explicit URL to the DTD. There's somewhere
to do that in SGML, but not for a style sheet or a navspec/table of contents
definition file, nor any other ancilliary non-SGML files. So we use
processing instructions in those cases where it's necessary.
Does that make a better case?
If people end up saying no, it's clear that all the commercial applications
will do this anyway, but each in their own incompatible way.
I hereby volunteer us to be amongst the first :-)
Liam Quin, email@example.com | lq-text freely available Unix text retrieval
Senior Technical Consultant | FAQs: Metafont fonts, OPEN LOOK UI, OpenWindows
SoftQuad Inc. +1 416 544-9000 | xfonttool (Unix xfontsel in XView)
http://www.softquad.com/ | the barefoot programmer
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (email@example.com)