a DTD as a JAR file resource [was Re: RFC: Simple XML Event-Based API for Java]

Peter Murray-Rust peter at ursus.demon.co.uk
Thu Dec 18 09:41:30 GMT 1997


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
(+versions), hotjava).
	- 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 [1]. Henry already has to test his CDROM for operation 
with HTML and JavaScript (sorry ECMAScript). The CDROM has to run anywhere
and for people who have no knowledge of:
	HTML
	JavaScript
	Who made the machine that they are viewing the CDROM on.
Adding:
	Java
	XML
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 :-(

demos
	mol.xml   
	mol.html
	<ancillary JUMBO files>
	jumbo
		sgml
			SGMLTree.class
		cml
			MOL.class
etc.

This runs OK with:
	java jumbo.sgml.SGMLTree mol.xml
or
	java jumbo.sgml.SGMLTree file:/C:/mydir/demos/mol.xml
or (I think)
	java.jumbo.sgml.SGMLTree file:mol.xml
and even
	java jumbo.sgml.SGMLTree mol.xml PARSER=AElfred

mol.html contains:
<APPLET CODE="jumbo.sgml.SGMLTree.class" WODTH=300 HEIGHT=300>
<PARAM NAME="commandline" VALUE="mol.xml PARSER=Lark">
</APPLET>
		
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
Applet Security?



[...]
>
>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 :-)

	P.
[1]
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
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)




More information about the Xml-dev mailing list