SML and false simplicity

[rev-bob at gotc.com]

> >All of a sudden, we're forgetting the *people* altogether and 
> >trying to see how simple we can make the *parser*
> 
> Reverand,

Please, just "Bob" works fine.  I go with the informal version for a reason....
 
> By the tone of your message, I get the sense that you
> assume 'we' collectively forgot what 'we' said before
> and are inconsistent or diverted.

Very good; that is exactly what I meant to say.

> This is not true.  Just as you are interested in 'easy
> to learn' aspect of SML, each of us come to SML with
> different needs.  I am interested in finding the right
> balance which could mean that no one will be completely
> satisfied nor deprieved.

Are you?  Some of the current concepts are *way* out in left field from the original 
"make XML easier to learn" proposal.  "Scrap DTDs because they're hard" is a long way 
from "get rid of attributes because we can use elements instead" and "get rid of decimal 
entities because we can get by with hex".  Here's a tip - keeping attributes is important 
because it draws an intuitive parallel with HTML, and that in turn makes the new 
language easier to learn via analogy.  Allowing hex and decimal entity values is important 
because Joe Newbie doesn't have to unlearn and relearn (or go through and convert) the 
values he already knows.

In terms of document syntax, I have to say that I find XML significantly simpler than 
HTML.  Instead of having to puzzle out whether <X> is an empty element or an opening 
container tag that will have a matching </X> down the line, I can just look at it and know 
- no slash, so it opens a container.  Simple, honest, cut-and-dried.  Instead of trying to 
figure out where an element ends by tracking down start tags that will imply an end tag 
where none exists, I look for the required end tag.  Why complicate things by trying to 
oversimplify the parser into something that requires nightmarishly complex 
documents...which are therefore orders of magnitude harder to "read and imitate"?  
About the only thing that confuses me on XML right now is making a DTD, and that 
primarily because still I'm trying to figure out how you tell a UA what it should do to 
render a given tag without putting it in terms of HTML.  ("Okay, I want this form 
element to display like a checkbox - how do I do that?")  As far as the actual semantic 
construction goes - well, it'd be a lot of work, but *hard*?  I ain't so sure.

I'm still of the opinion that the original "make XML easier to climb onto" goal is best 
addressed by putting training wheels on the *docs*, not on the *language*.  Take 
JavaScript, for instance.  JavaScript is a rather complex language if you get into all the 
depths of all the different editions - try to tackle it all at once, and you'll probably run 
screaming from the room.  On the other hand, if you swipe a couple of routines from 
existing web pages and examine them to see how they work, you can leverage your way 
up into a basic understanding of the language.  Once you get that down, you move into 
more advanced areas - and then, should you decide to venture further, you can explore 
the truly arcane realms.  Nobody says you have to learn it all at once...just like nobody 
says you have to learn XML all at once.  The question of learning JavaScript is not 
solved by dumbing down JavaScript, but in writing better documentation for the language 
as it exists, and that's been done a few times.  Why not try the same thing with XML, 
instead of splitting the spec and eventually confusing users all the more?

To put it bluntly - if the problem is the learning curve, fix the docs instead of rewriting 
the language.  Why reinvent the wheel when a perfectly good one already exists?

> If current SML threads are far-off target as you say,
> it is because not everything can be discussed at once.

That excuse only goes so far.  Some of the "simplification" ideas out there are downright 
arcane when it comes to usability - and the rationale behind these has been "we'll fix it in 
the API" and similar statements.  (Case in point - decimal entities; I was told specifically 
that the tools should handle the conversion, so the parser wouldn't have to.)  This is 
backwards; you have lost sight of your goal, and I'm calling you on it.  I don't care how 
slick the parser is; Joe Newbie is not going to be happy about trying to figure out:

<p><text>This is a paragraph with some</text><b>bold</b><text>text inside it that 
is</text><em>unneccessarily</em><text>separated from its context.</text></p>

That may be simple for the parser to handle, and the vaporware tools may make it easy 
to create the document, but the stated goal was "easy to learn," especially by example - 
and that example is anything but easy to learn from, unless the desired lesson is "go back 
to HTML."  (I was going to add a few stylistic directives and object handles - like an ID 
- in there, but I couldn't figure out *how*; what does that tell you about the simplicity of 
your new dialect?  Sure, maybe you *can* code without attributes - but only at the cost 
of a deeper and more error-prone element tree.)

> Also, you should bring up the issue of "easy to learn"
> whenever it seems relevent in any of the threads.

And I'm doing so right now - in a new thread, because the issue is global to all the 
existing SML threads.  Consider the gauntlet thrown; I hereby declare that the syntax-
minimization efforts under discussion are not merely irrelevant to the "easy to learn" 
goal, but rather they are *counterproductive* to that effort.  If anyone cares to 
demonstrate that I am wrong, have at it.  If this effort is truly on the Fast Track to 
Standard, this should be no problem at all.



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.com


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/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe 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)