RE: xml.com

Valid point.  When I view XSL, I view it from the view point of someone who
is going to have to write and maintain the compiler.  I want the best
marriage of ease of use and ease of integration.  If we refer back to the
last of the design rules for XML we are not worried about the terseness of
the code, rather whether it is human readable and easy to parse.

If I as a neophyte have a short and simple phrase such as:

<simple-selector name="body"><block>
	<rule><property name="display"/><value val="block"/>
	</rule></block>

I will know that this is a rule <rule>, I am working with a property named
display <property name="display"/>, and it has a value of block <value
val="block"?>.

The point being I don't have to spend a lot of time learning all the rules
if they are simple and easy to follow instead of lists and lists of
memorized attributes.  I teach classes in CSS and in XSL and the response
time to XSL consistently wins out over CSS.  Granted we don't have very many
metrics yet.

At this point I view the discussion as religious in nature and would rather
take it off line, unless the list feels it is germane.


-----Original Message-----
From: Steven Pemberton [mailto:Steven.Pemberton@cwi.nl]
Sent: Monday, June 21, 1999 2:49 AM
To: Barry van Oven
Cc: www-style@w3.org
Subject: RE: xml.com


Barry van Oven writes:
 > Daniel Koger wrote:
 > "I fail to see what is inherently complex about XSL.  It basically does
one
 > of two things with an element or object.  It either applies a
programmatic
 > response, or affects a style change.  Complex?"
 > 
 > My point exactly! The best thing about XSL is, that you need only one
 > language for these two things, instead of a combination of a stylesheet
 > language (CSS), an interface language (DOM), and a programming/scripting
 > language (JavaScript, C++, Java, etc.).

I first came across this attitude in the 70's when I was looking over
the shoulders of two students who were obviously having difficulties.

They were writing things like:

	run pip/c src=foo.txt dst=bar.txt

I asked them what they were doing and they said that they were trying
to make a copy of a file. "Oh easy!" I replied, you just type

	"copy foo.txt bar.txt"

and from that point on they were happy.

I then went to talk to their teacher to tell him that there was a far
easier way to copy files than he was telling them. He replied that he
knew and did it deliberately, since it was simpler if they only had to
learn the "run" command, rather than having to learn lots of different
commands.

The point is, what is easy for the computer is not necessarily easy
for the human.

Part of the problem is that computer scientists have in general a
quite different psychological makeup from the general public, and so
often don't see the problem. They are perfectly happy to look at a
complex encoding and "see through" the encoding. (I seriously
recommend reading the chapter on "The Goldilocks Theories" in the book
"Tog on Interface" by Bruce Tognazzinni for an amusing and interesting
description of this).

The thing is, people don't mind learning a new language if it allows
them to express their thoughts closer to the problem domain. It
actually makes life simpler for them. The only person for whom

	<if><rel op="less than"><var name="a"/><constant value="0"/></rel>
	<then><set><var name="a"><expr><neg><var name="a"/></neg></expr>
	</set></then>
	</if>

is easier than

	if a < 0
	then a= -a

is the writer of the compiler.

There is a second misunderstanding in the two mails quoted above. XSL
is *encoded* in XML, but XSL is still a language you have to
learn. You could encode CSS in XML:

	<simple-selector name="body"><block>
	<rule><property name="display"/><value val="block"/>
	</rule></block>

but the *language* is still

	body { display: block; }

and the XML version would *not* be easier to use.

Steven Pemberton

Received on Monday, 21 June 1999 09:43:27 UTC