Re: Scripting DTD's

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Aaron,

Am Freitag, 14. November 2003 22:12 schrieb AaronEldreth@cs.com:
> lhunt07@postoffice.csu.edu.au wrote:
> > XHTML is not and should not be a programming language.
> Why?
The definition of programming is a language in which it is possible to 
describe algorithms.
An algorithm is a computer science formula based on the register machine 
model.
JavaScript, Java, C, Assembler, C++ all are programming languages, even XSLT.
But XML, XHTML, SGML, CSS are not programming languages.
They are computer languages, not programming languages.

XHTML also should not be a programming language because programming requires a 
very different kind of knowledge than document authoring, which is much 
easier (yet difficult enough if to be done wisely).

Also, the purpose of XHTML is to give some structural markup for hypertext. 
That's got nothin' to do with programming.
Extending XHTML to a programming language would also require much thoughts:
a) Is it server side, client side or both?
b) What about communication?
c) What object and type model?
d) Can it have any advantages over PHP, ASP, JSP, JavaScript, Java Applets, 
Flash, Perl, XSLT and all other languages in web use?

I especially can't imagine any "yes"s for d).


> > XHTML is called "Extensible HyperText Markup Language", NOT "Extensible
>
> HyperText
>
> > Multipurpose Language", and, therfore, it is designed for marking up
> > structure in documents only, and that's how it should stay. Scripting
> > XML documents is the domain of the Document Object Model [DOM] and the
> > scripting language standards, like ECMAScript [ECMA-262].
>
> This is true. Even I will give that credit, exept for one thing. The DOM
> would still be necessary,
> otherwise it would be impossible to access elements. Unless my idea were
> taken even
> further, and allowed people to create their own DOM, but that would get
> UGLY.
Why should we have a MetaDOM for creating a DOM? The DOM is abstract and 
generic enough.

> ECMAScript
> is supposed to be the great universal scripting language for the web,
> unfortunately,
> few people use it. How many pages have you looked at that the designer used
> ECMAScript?
Well,
a) Yet many more pages use ECMAScript than it would be neccessary if user 
agent vendors would correctly implement HTML4.01 and CSS Level 2.
b) Another reason for not using ECMAScript is that obviously technology is 
advancing faster than user agent vendors can keep up with. Currently, user 
agent vendors are busy enough catching up with recent recommendations. 
Especially DOM is a problem here, it differs too much from implementation to 
implementation because during the browser war the user agent vendors invented 
their own DOMs instead of implementing the W3C's drafts. A draft is a draft 
and might change, so an implementation is always somewhat critical, but 
implementing completely different stuff, as MS and Netscape did, is even much 
much worse.

> To allow people to create or structure their own languages by a Scripting
> DTD, would give
> more power and flexibility to designers, weather they need a simple
> If...Then, for their page,
> or a vigorous Do Loop Until. This would allow more cross-browser-scripting,
> without the
> use of a language few people use. And if it were designed correctly, all
> browsers with
> DTD or XMLNS capability could read and decipher it.
Oh, if a designer can't handle a simple if then with the easy JavaScript 
syntax, that's not the problem of (X)HTML, sorry ;-)

> If people refuse to change XHTML, create a new language that would support
> the "Extensible HyperText Multipurpose Language".
No, no and definitely not yet.
User agent vendors need to catch up with recent recommendations and RFCs 
first.
It's not that I wouldn't like an extensible hypertext multipurpose language. I 
also could imagine of another programming language next to XSLT with XML 
based syntax, this time designed for scripting, with its own namespace and 
such, but to be of real use it must be handled with regular XML tools, like 
XSLT, such a language would be a real language suited for document authors, 
but on the other hand, think of what people sometimes criticize about XSLT: 
it's XML based syntax.

Of a DTD for changing the language I could not think of. I would not like it.
A usual programming language is well defined and has it's well defined set of 
keywords, expressions, statements, blocks, definitions and other syntactic 
constructs.
It's like with human languages. Think of the world if everyone defines his/her 
own language.
Think about the even decreased maintainability of web sites if with every site 
I take over to maintain I'd need to learn a new programming language just 
because the author couldn't cope with the existing general purpose 
programming languages like JavaScript, Perl or PHP.

It's not that I hate invention or learning new languages. But in learning e.g. 
PHP or Perl I see some sense: I can use them over and over again and again, 
and they are, especially Perl, somewhat generic and multipurpose.
And every problem needs its tool.

But allowing web authors to invent their own programming languages is creating 
a Babel in the Web and would swamp the web with superfluous languages that do 
not have real advantages over the others.

Take a look at the market of programming languages: Only languages with real 
advantages over other languages, be it technical or marketing advantages, do  
survive. Pascal is dead because of Delphi, Modula-2 and Oberon. Modula-2 and 
Oberon are dead because of C++ and Java. Perl is popular because it's free 
and has true advantages for computer linguists.

What would be the advantage of your language concept, Aaron?




Bye
- -- 
ITCQIS GmbH
Christian Wolfgang Hujer
Geschäftsführender Gesellschafter (Shareholding CEO)
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: Christian.Hujer@itcqis.com
WWW: http://www.itcqis.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/uKrnzu6h7O/MKZkRAiJpAKDRKWFYba8oU4IgBZ1apRxJNlDBqQCeMNL+
3PN0Oe6EdxgLzVKPUuD/LDw=
=R8mW
-----END PGP SIGNATURE-----

Received on Monday, 17 November 2003 06:05:09 UTC