OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] What is XML For?

[ 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 

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


A city is like a large, complex, rabbit
 - ARP


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS