Lists Home |
Date Index |
Alaric B. Snell wrote:
> On Tuesday 29 October 2002 16:20, Paul Prescod wrote:
>>No, actually, I don't see it as being easier for a computer to keep a
>>stateful mapping of columns to column titles.
> Storing the list of column titles from the first line being easier than what,
> the state management of an XML parser?
Okay, fair enough with the appropriate CSV parser library, the CSV state
management is magically handled for you and with an XML parser, all of
the XML syntax is handled for you. Either way there is very little
difference in programmer effort.
> s-exprs are nicer since they EXPLICITLY express the graph structure; general
> tools can deal with the graph. With XML, there is no way to pull out the
> references other than parent/child relationships except where people have
> used xlink, which does not seem to currently be as ubiquitous as one would
I agree that a standardized linking semantic would be helpful and have
fought for that at every opportunity. If the XML world could agree that
this is a problem then it would be trivial to solve. XLink is one
solution. An even simpler one is
> 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.
>>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!
> ...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). Scheme also does not have
keyword arguments ("attributes").
I'm not as familiar with CommonLisp so I'd be happy to be educated if
they have some of these features.
> 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!
> 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.
> ... since if so we'd include
> Scheme as our transformation and schema language, no?
> 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.
> 3) Family matters
> Ahah! So you're comparing complex, limited, and inconsistent schemas,
> infosets, xpaths, xqueries, and xslt against Scheme and (whisper lest you
> waken him!) his big brother Lisp? Muhahahah!
> 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:
>... 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
>>The Web as we see it has stagnaged since Microsoft wiped out Netscape.
>>But all of the most innovative emerging technologies on that front are
>>XML-based: RSS, SVG, XUL, XForms. It is way too early to say that XML
>>didn't change the Web. Give it five years.
> It hasn't changed it yet, though, and the momentum to do so seems to be
> waning; once I kept hearing people asking "Um, should we be using XML for
> this stuff?" but now they're back to their HTML templates and (grumble) CGIs
> with code and HTML entwined.
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.
My local XML user's group is as popular as ever. When most developers
need to dump some state of their applications they instinctively use XML
today. If they are making an interchange format then they are even more
likely to use XML. People rejecting the SOAP hype tend to fall back to
either XML-RPC or application-specific 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.
> That thing's just dynamic uploading and downloading of files via HTTP, isn't
> it? When I run a program over NFS, it's fast because the file is demand paged
> over the network, it doesn't have to wait until it's downloaded the whole
> thing before it can get started!
Does it make sense to you that you couldn't start processing the first
bits of an HTTP GET before you get the last? I'm not going to go through
all of the details of HTTP/WebDAV, but yes, it has incremental
up/download, pipelining, multiple TCP sockets, byte range updates, etc.
> 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:
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.