RE: Interactive XML

	>At 00:15 01/07/98 +0200, Chris Lilley wrote:
	>>Thats an interesting use of the word portable.
	>>
	>>Even if the languages are extended to two - ECMAScript and
Java 1.2, say
	>>- that doubles the implementation load for anyone writing a
conformant
	>>implementation. Or alternatively, it requires softening the
conformance
	>
	>I use java because it is platform-independent (and can be run
with or
	>without a browser). Is ECMAScript available in standalone form
(i.e.
	>without a browser)? If so, I may come to learn to love it - if
not, it
	>makes standalone XSL impossible which is a serious drawback.

	What your talking about is not the language itself but what kind
of parsers exist and what the parsers understand. Let's look at some
examples.

	First off, we'll look at VisualBasic. Most of would agree that
VB is a power yet simple programming language. Due to my involvement
with C++, I try to learn as must as I can about Visual C++. Did you know
VB was created with VC++?

	Private Sub Form_Activate()
		Printer.FontName = "Courier"
		Printer.CurrentX = 1440
		Printer.CurrentY = 2880
	End Sub

	The code above is VB and it sure doesn't look like C++. Now that
I think about it, C++ doesn't look like machine code. How does this
work? The compiler parses the document before converting the document.

	I think that the major dispute about Interactive XML is that
some people are trying to use XSL to make XML as dynamic as a
stand-alone executable. While, IMHO, I don't think XML was designed for
this, I do think that people would use an Interactive version of XML.

	To implement a more advanced programming language that can be
included in XSL, we would have to write our own parser. The W3 has done
an execllent job in setting a minimal standard that should be used, but
the standard cannot appeal to all. Here's the situation:

	1) Give uses the ability to use JScript, JavaScript, Java,
DSSSL, C++, Smalltalk, machine code, ect. and you'll overkill what the
average person will need.

	2) Give us nothing but a watered down version of HTML and watch
people develop add ons and make XSL into HTML.

	Don't extend the standards because a few people have a problem.
Try to work around the problem. Here are a few things that I could think
of for some work around solutions:

	1) Make an ISAPI extension that would allow your server to
display most of the information. Why should all servers preform slow?
Just restrict it to the servers trying to dish up massive amounts of
information.

	2) If your going to use XSL as a stand-alone parser, you should
work on develping a custom parser with a language extension. Follow the
lead of James Clark with DSSSL...

	3) What about a translator that would take a language like Java
and convert it into EMAScript? It would be difficult to do but it would
get the job done.

	4) Use Java applets on the web.


	~~ Daniel T. Hable ~~
	SGML/XML/C++ Application Developer
	XLink Corporation


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list