Subject: Re: SGML/XML syntax for DSSSL From: Paul Prescod <papresco@xxxxxxxxxxxxxxxxxxxxxxxxx> Date: Mon, 19 May 1997 11:33:46 -0400 |
Mitch C. Amiano wrote: > That suggests using a syntax that at the highest level of perusal is > cosmetically similar to HTML, and it probably should be XML compliant. > This would give it an added advantage over CSS, in providing, at least > for a casual user, "one syntax" to learn. I'm not so sure on this point. XML syntax will probably be comfortable for people used to SGML or XML, but it seems just as foreign to HTML users as CSS. It uses angle brackets, true, but the tag names are all totally different. They will notice that immediately and think: "this is a totally different language." This syntax DOES have the benefit of being familiar to those who are already familiar with the concepts of generalized markup (SGML and XML users). The benefit of a CSS-like syntax seem twofold: #1. By the time XML-stylesheets ship CSS will have been widely deployed for quite a while. I don't have a way of measuring how many users will have seen it, though. #2. CSS's curly bracket syntax is closer to the infix syntax of popular programming languages. If we decide to use that syntax for programming (as I am advocating) then the regularity will be useful. If we decide NOT to allow procedures in DSSSL then we would almost certainly want to go with XML syntax. If we decide to allow parenthesized-prefix procedures in DSSSL we would probably still want to go with XML syntax. If we decide to allow un-parenthesized C/Perl/Java-like syntax then we should consider a similar syntax for code. > A similar problem is faced by RAD development environment vendors. The > solution usually provided is similar: a "syntaxless" interface which > saves/exports to a serialized representation of objects and scopes, and > a programming language which is edited directly using your favorite text > editor. This convergence could be due to to a total lack of creativity, > but it could also be because it's a best-fit design given the available > technology, and know-how, and OO biases of the market. That is true. So there is a precedent for treating declarative and programming issues separately. Note that there is also a counter-trend among RAD DEs for something they call "two-way" tools which allow the visual manipulation of constructs that are immediately reflected in Pascal/Java/DBase code or the textual manipulation of constructs Pascal/Java/DBase that are immediately reflected in the GUI. So there is also a precedent for a single syntax that can be controlled either way. > > I think this stops being natural when you start trying to doing programming. > > But for this, an alternative syntax seems less important to me: the fact > > that you have to program in a functional way is a far bigger leap for a > > C/C++/Java programmer than is the syntax. > > The perception of having to "program" at all will be a more significant > inhibitor. It depends who we are talking about. For most end-users any programming is an inhibitor. I don't think that casual end-users are very relevant, because they will probably not use SGML/XML/DSSSL at all, when they could just use HTML. The most crucial constituency seems to be the massive middle ground of people who know how to program and are not afraid of it, but don't want to learn something very foreign. This ranges all the way from people who do most of their programming in Excel and Javascript to professional programmers who spend most of their day in Perl or C/C++. It seems to me that these are the people who will really determine the success of new languages. Real "end users" will use whatever these people tell them is good, either explicitly, or through training courses, or through the tools (e.g. GUIs, converters) that these programmers provide them. > I'll go back to lurking now, but, for the sake of clarification, is this > discussion > about an application-of/front-end-for DSSSL, or a variation of DSSSL > itself? I don't think anyone is talking about changing the ISO standard. I am proposing a W3C specification that uses the same data-model, procedures, features etc. as DSSSL but a syntax more in line with the W3C vendors' customers' preferences. Perhaps the same specification would outline both syntaxes. Or maybe it would be just a proprietary second syntax implemented by some DSSSL implementations in response to their customer demand. It could be implemented as a Scheme-transformed front-end for an existing DSSSL implementation, as a syntactic "peer" through a second parser or as an independent language. Paul Prescod DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: SGML/XML syntax for DSSSL, Mitch C. Amiano | Thread | Re: SGML/XML syntax for DSSSL, Alex Milowski |
Re: Heresy? Re: DSSSL WWW Enhanceme, Paul Prescod | Date | Tail Recursion (was Re: Jade reques, David Megginson |
Month |