Lists Home |
Date Index |
- From: firstname.lastname@example.org
- To: email@example.com
- Date: 30 Nov 99 12:20:46 -0500
> >All of a sudden, we're forgetting the *people* altogether and
> >trying to see how simple we can make the *parser*
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
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
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:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)