Lists Home |
Date Index |
- From: Peter Murray-Rust <email@example.com>
- To: firstname.lastname@example.org
- Date: Thu, 18 Dec 1997 10:34:17
At 18:50 17/12/97 -0800, Russell East wrote:
>Yes! I would like to be able to store one or more DTDs as
>resources within a JAR file. Within a <!doctype ... SYSTEM "URL">
>I'd like to be able to refer to that DTD, rather than, refering
>to some server-side DTD. But, I don't think we can do this now, because,
I think this is a tremendously important subject, Russell - thanks. One of
the exciting aspects of SGML/XML over the WWW is that it makes it possible
to distribute a whole environment. Like you I would want to be able to
"cache" some or all of these resources "client-side". One obvious reason is
slow lines, another is that people are often not connected to the WWW. For
example JUMBO - when used for molecular, statistical and other non-core XML
operations can be over 500Kb in classes.
>It would be good to be able to specify one of these URLs in SYSTEM,
>and have it work in all cases - not just appletviewer.
Personally I have enormous trouble with URLs under Java. There are the
following orthogonal problems:
- file: versus http:
- different syntaxes for files ('/' versus '\')
- different compilers (jvc vs javac)
- different JVMs (appletviewer, java, jview, NS (+versions), MS
- different platforms (UNIces, Mac, Windows).
Altogether there are at least 20 actual variants.
For example, I contributed a JUMBO snapshot for Henry's latest CDROM on
chemical publishing . Henry already has to test his CDROM for operation
and for people who have no knowledge of:
Who made the machine that they are viewing the CDROM on.
is yet another dimension.
The ability to publish packaged systems under Java/XML is tremendously
exciting. I've done this in a limited way earlier this year and it seemed
to work. Henry's CDROM is going out with an issue of a paper Journal from
the Royal Soc of Chemistry but I don't expect a lot of feedback about JUMBO
- I suspect that most people won't get that far through the distribution
(the main rationale is *content* - organomettallic chemistry.)
A bizarre problem has just arisen. Please help me :-). The JUMBO snapshot
is arranged to run under a browser as well as a standalone interpreter. So
I have packaged it as this directory structure (not horizontal as hypermail
won't render it :-(
<ancillary JUMBO files>
This runs OK with:
java jumbo.sgml.SGMLTree mol.xml
java jumbo.sgml.SGMLTree file:/C:/mydir/demos/mol.xml
or (I think)
java jumbo.sgml.SGMLTree mol.xml PARSER=AElfred
<APPLET CODE="jumbo.sgml.SGMLTree.class" WODTH=300 HEIGHT=300>
<PARAM NAME="commandline" VALUE="mol.xml PARSER=Lark">
When mol.html was loaded this used to work fine, launching JUMBO and
reading the file. Henry tells me that it still works for him under Netscape
4.04. BUT on my own PC with NS4.02 it now throws a SecurityException when
it comes to read file:/C:/cdrom/demos/mol.xml saying it isn't allowed to
read a local file.
So it seems to be a PMR-environment-specific problem. Help would be really
appreciated. Are there any browsers switches, config files etc that I might
have corrupted? Or is everyone benefitting by a laxer implementation of
>Do the XML parser developers have any suggestions on how to achieve this?
I don't think it's just for parser developers - anyone can play.
>Does it make sense to have a special API for the parser through which
>you can not only specify an xml document, but also a separate dtd ?
I think this is part of the namespace activity. JUMBO implements
namespaces experimentally (all namespace stuff is experimental!) and it
involves a lot of subsidiary files (JUMBO has one for most ELEMENTs, schema
files and much more). JUMBO can also use 3 parsers and will - by Jan 12
;-) be able to use 5. As we've seen, these parsers provide additional
features so that it makes sense to distribute them (authors permitting of
course) with the JUMBO distribution. It's also possible - as you suggest
that different DTDs (or, I suspect namespaces) might be distributed as
well. For example, it could make sense to have a variety of support files
for HTML4.0/XML. The reader could then choose between these at browse time.
This requires something with the functionality of a JAR file. I take the
concern that we shouldn't become Java-only, but I think the *experience*
with JAR files for early XML adopters will be essential. So - not for Jan
12 - some communal activity here on distribution, manifests, installation,
etc would be extraordinarily helpful to the success of XML. If we can
reliably distribute our XML applications without worrying about what's at
the other end it would be marvellous. It's a very different sort of task
from writing a parser :-)
Some people may not know who Henry Rzepa is. Henry is the world's leading
exponent of the use of the Internet and related technologies for chemical
information and publishing. [He also does mainstream research in
computational chemistry.] He has run 3 major electronic conferences on
chemistry (content-driven) and published these with the Royal Society of
Chemistry through an E-lib project, CLIC. This project, including
Cambridge, Leeds and IC is committed to the use of SGML/XML as a publishing
tool. This explains some of his and my enthusiasm for seeing XML succeed.
Our primary concern is to see the link between author and reader as direct
as possible without information loss or corruption.
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)