[
Lists Home |
Date Index |
Thread Index
]
On Wednesday 30 October 2002 01:17, Paul Prescod wrote:
> > How do you mean multiple syntaxes? I presented a single syntax that
> > handles many cases neatly. My thing for embedding styling in s-expr
> > strings was a grotesque hack to make it look like HTML; a more elegant
> > shorthand could be had, I'm sure.
>
> I'm all ears. It won't be s-expressions and it won't be anything that
> fits naturally with the pre-existing markup model of the Web.
XML didn't fit naturally with the pre-existing data model of transaction
processing systems and when it was being designed and it was just a labelled
tree format against the huge installed base and existing toolset of EDI
systems and RPC protocols and whatnot; where you using these same arguments
to quash *it* then? :-)
As for a nice shorthand for embedding structure in strings... well the
general problem is that
... blah blah " (<stuff> <stuff> " ... blah ... " <more stuff>) " ...
is messy with the quotes.
Let's say that, in strings, <stuff stuff> maps to " (stuff stuff " and that
</stuff stuff> maps to " stuff stuff) ". You can use the existing \ syntax to
escape literal < signs.
So we could write:
"This is some text with a <link url: "http://www.alaric-snell.com/";>link</>
in it"
to mean:
"This is some text with a " (link url: "http://www.alaric-snell.com/"; "link"
) " in it"
It's open to debate whether you want to enforce that the body of such a node
be the last argument, in which case the option for trailing arguments in the
closing tag should be removed.
I think it's probably fine to leave it with an empty closing tag, though,
since this construct is intended for inline styles only and not for stuff
that stretches over many lines. Votes? :-)
> >>You aren't talking about s-expressions anymore. You're talking about a
> >>syntax you invented.
> >
> > No I'm not. This is standard s-expr stuff from the Lisp days.
> >
> > Here it is! Used # symbols, not @s. My bad!
> >
> > http://www.cs.rice.edu/CS/PLT/packages/doc/mzscheme/node153.htm
> >
> > ...ugh, they mandate using numeric identifiers, I prefer my
> > interpretation with symbols after all :-)
>
> That's MZScheme-specific syntax, not standard Lisp s-expressions (I know
> for a fact that it isn't legal Scheme).
Hmmm, that's the only useful page Google returned (far too many pages refer
to Lisp and graphs together!) but the original book I read it in spoke of it
as Lisp syntax. It might have been a copy of CLTL I read in a library...
> Scheme also does not have
> keyword arguments ("attributes").
>
> http://www.swiss.ai.mit.edu/~jaffer/r5rs_9.html#SEC74
Common Lisp definitely does / did, though.
http://www.psg.com/~dlamkins/sl/chapter03-11.html has some examples.
> > They have the graph feature, and the other two are just syntactic sugar
> > to please people who don't like all the ()s.
>
> In a markup language, a feature allowing text to be "marked up" (as
> opposed to quoted) is not syntactic sugar!
It's semantically identical, it's just a shorthand for the long form!
> > We can *make* a schema language. I'm comparing XML with s-expressions
> > here, not "The world of XML" with just s-expressions,
>
> XML 1.0 has a schema language called "DTDs" in it. Many people used it
> productively for the several years until replacements came along as
> during the decades when there was only SGML.
DTDs could just have easily been a seperate spec, and I suspect many would
prefer it if they had :-)
Comparing equivelant *concepts* from the two camps, s-expressions <-> the
basic core of XML.
> > ... since if so we'd include
> >
> > Scheme as our transformation and schema language, no?
>
> No. POLP.
But I don't agree with that as it stands anyway :-) I'm more for a principle
of least complexity, on which the XML world as a whole is starting to lose
out :-/
> > 2) Redundancy is Good
> >
> > I showed a trivial fix for this problem with my [foo[ ... ]foo] concept,
> > which I've implemented with success before, and would submit to the
> > Scheme standards bodies if I thought it mattered *that* much.
>
> The point is that you are not comparing s-expressions as they are with
> XML as it is. You are comparing "S-expressions, if the people who
> invented them took all of the best ideas from XML and added them to
> s-expressions." Fine. In that circumstance you are probably right that
> s-expressions would be better than XML by virtue of having merged its
> best ideas with theirs.
Yep, and the shame is that they didn't do this in the first place,
reinventing the wheel and leaving bits off!
> > 3a) Principle of Least Power
> >
> > That's missing a point - it confuses Power with Complexity, I suspect.
>
> No. Principle of Least POWER. Complexity is irrelevant. Note how it is
> discussed completely independently of simplicity here:
>
> * http://www.w3.org/DesignIssues/Principles.html
"Computer Science in the 1960s to 80s spent a lot of effort making languages
which were as powerful as possible. Nowadays we have to appreciate the
reasons for picking not the most powerful solution but the least powerful.
The reason for this is that the less powerful the language, the more you can
do with the data stored in that language."
Therein lies the problem, I think... but he then goes on to say:
"If you write it in a simple declarative from, anyone can write a program to
analyze it in many ways. The Semantic Web is an attempt, largely, to map
large quantities of existing data onto a common language so that the data can
be analyzed in ways never dreamed of by its creators. If, for example, a web
page with weather data has RDF describing that data, a user can retrieve it
as a table, perhaps average it, plot it, deduce things from it in combination
with other information. At the other end of the scale is the weather
information portrayed by the cunning Java applet. While this might allow a
very cool user interface, it cannot be analyzed at all. The search engine
finding the page will have no idea of what the data is or what it is about.
This the only way to find out what a Java applet means is to set it running
in front of a person."
That's a different issue entirely. That's an argument for having standard
interfaces to data rather than anything to do with power. He's confusing
programming languages with data description languages. No site sends you
weather information in the form of a Java applet! They'd have to compile it
up again each time the weather changed! Instead they send you a Java applet
which then uses some interface to fetch the weather from the server. The
power of the data language is unrelated to whether you provide an applet
interface to it; the real problem in those situations is that the sites might
not bother to expose the data interface for users other than their Java
applet.
And what does this have to do with the power of Scheme vs. XSLT? Both are
Turing complete, so you could compile Scheme into XSLT and vice versa; ergo
there's nothing somebody viewing an XSLT stylesheet as data can do that they
can't do with the equivelant Scheme code.
Now while the RDF weather data can be converted into a Java applet, the Java
applet can't be converted back into RDF weather data without a human to
reverse engineer it, wherein the problem lies.
> >... A scheme runtime is going to be similar in complexity
> >
> > to an XSLT engine, actually, and it'll be able to do more!
>
> A scheme runtime is, in general, a Turing-complete runtime. Which means
> that introspecting into them is difficult and in some cases absolutely
> impossible. It is all layed out in the URI above. Tim B-L specifically
> points out that using a full programming language is usually the wrong
> choice for a web format (unless it is really intended to provide
> "behaviour").
Read your own URL.
"...through those which are in fact Turing Complete though one is led not to
use them that way (XSLT, SQL)"
XSLT *is* Turing-complete, unless that URL's wrong (I thought it was TC
anyway since you can recurse and branch). Sorry. Are you going to start
arguing that people shouldn't use it now? :-)
> In my view, XML's momentum is great. This week I'm investigating
> handhelds. I'm told that in 2003/2004 advanced models will all ship with
> SVG support built-in.
>
> * http://www.w3.org/2002/04/svg11-testimonial
SVG's the first reasonable vector format I've seen suggested for the
Interweb, though, quite independant of anything to do with it being XML...
> It would be a good thing if some of the air was let out of the XML
> balloon. I'm confident that people will use it because it is useful, as
> they did before marketers filled the balloon with hot air.
Give it a decade... although the last marketing wave often becomes the target
of the next one. "Client / Server", anyone?
> > They might be using range requests to speed up reading, and perhaps you
> > can PUT to a range in a resource and have the server understand you, but
> > even then you still have no standard way to represent chmod, chown, and
> > chgrp or ACL changes!
>
> I'm not saying that WebDAV is a drop-in replacement for NFS. Probably,
> it is better that it isn't, for the reasons discussed here:
>
> * http://research.sun.com/techrep/1994/abstract-29.html
NFS does all of those things!
> I'm just saying that it does things that you claim are impossible. If it
> doesn't do CHMOD, CHOWN, CHGRP etc. (because those are Unix-specific
> concepts) it is very easy to imagine how those could be built on top of
> it using the properties mechanism.
Just as my stuff could probably be built on top of s-exprs using the
extensible parsing model in Common Lisp :-)
Not that I would recommend that practice, mind. CL needed a trimming, and
Scheme was the result. They overtrimmed a bit but seem to be spending the
time since profitably producing cleaned up versions of the more useful bits
of CL they originally trimmed off.
> Paul Prescod
ABS
--
A city is like a large, complex, rabbit
- ARP
|
