[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] SML and false simplicity
> >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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|