Re: SGML/XML syntax for DSSSL

[Paul Prescod <papresco@xxxxxxxxxxxxxxxxxxxxxxxxx>]

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